Производительность длинных идентификаторов

Question

Я долго об этом думал. В CouchDB у нас есть несколько лог-идентификаторов ... например:

"000ab56cb24aef9b817ac98d55695c6a"

Теперь, если мы ищем этот элемент и просматриваем древовидную структуру, созданную представлением. Кажется, простое целое число в качестве идентификатора будет намного быстрее. Если бы мы использовали 64-битные целые числа, это был бы простой CMP, за которым следовал JMP (при условии, что в коде Эрланга использовался JIT, но вы меня поняли).

Для строк я предполагаю, что мы генерируем хеш из идентификатора или чего-то еще, но в какой-то момент мы должны выполнить сравнение символов по всем 33 символам ... не повлияет ли это на производительность?

Answer 1

Короткий ответ: да, конечно, это повлияет на производительность, потому что длина ключа напрямую влияет на время, необходимое для перехода по дереву.

Это также влияет на память, так как более длинные ключи занимают больше места, а пространство занимает время.

Однако нюанс, который вам не хватает, заключается в том, что хотя Couch CAN (и делает) выделил для вас новые идентификаторы, этого не требуется. Он будет более чем счастлив принять ваши собственные идентификаторы, а не создавать свои собственные. Таким образом, если длина ключа вас беспокоит, вы можете использовать более короткие ключи.

Однако, учитывая "json" характер couch, это в значительной степени текстовая база данных. В обычном экземпляре Couch не так много двоичных данных (вложения не выдерживают, но даже те, которые, как мне кажется, хранятся в BASE64, могут ошибаться).

Итак, хотя 64-разрядный вариант будет наиболее эффективным, простой факт заключается в том, что Couch предназначен для работы с любой клавишей, а «любая клавиша» наиболее легко выражается в тексте.

Наконец, по правде говоря, стоимость сравнения ключей уменьшается из-за времени выборки дискового ввода-вывода и маршалинга данных JSON (особенно при записи). Любой реальный выигрыш, достигнутый путем преобразования в такую ​​систему, скорее всего, не окажет никакого влияния на реальную производительность.

Если вы хотите по-настоящему ускорить систему ключей Couch, закодируйте процедуру ключей, чтобы заблокировать ключ до длинных 64-бит, и сопоставьте их (как вы сказали). 8 байтов текста - это то же самое, что и 64-битное «длинное целое». Теоретически это даст вам 8-кратное увеличение производительности при сравнении ключей. Могу ли Эрланг создать такой код, я не могу сказать.

Answer 2

Из CouchDB: полный путеводитель:

Мне нужно нарисовать это на какой-то момент, но причина в том, если вы думать об идеализированном дереве, когда вы использовать UUID, вы можете ударить любой количество корневых узлов в этом дереве, так с добавлением только природы у вас есть написать каждый из этих узлов и все выше этого в дереве. но если вы используете монотонно увеличивая идентификаторы, то вы аннулируете тот же путь вниз по правой стороне дерево, таким образом, сводя к минимуму количество узлы, которые нужно переписать. было бы быть точно таким же для монотонно также уменьшается. и это должно технически работать, если вы обновления можете гарантированно ударить один или два узла хотя внутри дерева это гораздо труднее доказать.

Таким образом, последовательные идентификаторы обеспечивают выигрыш в производительности, однако вы должны помнить, что это невозможно обслуживать, если у вас более одной базы данных, поскольку идентификаторы будут конфликтовать.