Производительность длинных идентификаторов
Я задавался вопросом об этом в течение некоторого времени. В CouchDB мы имеем, некоторые справедливо регистрируют идентификаторы..., например:
"000ab56cb24aef9b817ac98d55695c6a"
Теперь, если мы ищем этот объект и проходим древовидную структуру, созданную представлением. Это кажется простым целым числом, поскольку идентификатор был бы намного быстрее. Если бы мы использовали целые числа на 64 бита, то это был бы простой CMP, сопровождаемый JMP (предполагающий, что код Erlang использовал JIT, но Вы понимаете мою мысль).
Для строк я предполагаю, что мы генерируем хеш от идентификатора или чего-то, но в какой-то момент мы должны сделать, символ выдерживает сравнение на всех 33 символах... разве, которые не будут влиять на производительность?
2 ответа
Короткий ответ: да, конечно, это повлияет на производительность, потому что длина ключа напрямую повлияет на время, необходимое для обхода дерева.
Это также влияет на хранилище, так как более длинные ключи занимают больше места, пространство требует времени.
Однако нюанс, который вам не хватает, заключается в том, что, хотя Couch МОЖЕТ (и выделяет) для вас новые идентификаторы, это не требуется. Он будет более чем счастлив принять ваши собственные идентификаторы, а не создавать свои собственные. Итак, если вас беспокоит длина ключа, вы можете использовать более короткие ключи.
Однако, учитывая "json" природу couch, это в значительной степени "текстовая" база данных. В обычном экземпляре Couch хранится не так много двоичных данных (вложения не выдерживают, но даже те, которые, как мне кажется, хранятся в BASE64, я могу ошибаться).
Итак, хотя да, 64-битная версия была бы наиболее эффективной, простой факт заключается в том, что Couch разработан для работы с любой клавишей, а «любая клавиша» наиболее легко выражается в тексте.
Наконец, по правде говоря, стоимость сравнения ключей меньше, чем время выборки дискового ввода-вывода и маршалинг данных JSON (особенно при записи). Любая реальная выгода, полученная при переходе на такую систему, скорее всего, не окажет «реального» влияния на общую производительность.
Если вы хотите действительно ускорить систему ключей Couch, закодируйте подпрограмму ключей, чтобы заблокировать ключ, на 64-битные длинные и сравните их (как вы сказали). 8 байтов текста - это то же самое, что и 64-битное длинное целое число. Теоретически это даст вам 8-кратный прирост производительности при ключевых сравнениях. Я не могу сказать, может ли erlang создать такой код.
Из CouchDB: Полное руководство:
Мне нужно нарисовать это в какой-то момент, но причина если вы думаете об идеализированном btree, когда вы используете UUID, вы можете попасть в любое количество корневых узлов в этом дереве, поэтому с добавлением только природа у вас есть для записи каждого из этих узлов и всего, что находится над ним в дереве. но , если вы используете монотонно увеличивающиеся идентификаторы , то вы аннулируете тот же самый путь в правой части дерева , тем самым минимизируя количество {{ 1}} узлы, которые необходимо переписать. будет таким же и для монотонно убывающего . и он должен технически работать, если ваши обновления могут гарантированно попасть в один или два узла внутри дерева, хотя это намного сложнее чтобы доказать.
Таким образом, последовательные идентификаторы дают преимущество в производительности, однако вы должны помнить, что это не обслуживается, если у вас более одной базы данных, поскольку идентификаторы будут конфликтовать.