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

"000ab56cb24aef9b817ac98d55695c6a"

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

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

5
Timothy Baldridge 1 Фев 2010 в 17:52
Спасибо за ответы. Мне действительно нравится элегантность, которую позволяют более длинные идентификаторы строк. И теперь мои опасения по поводу производительности уменьшились.
 – 
Timothy Baldridge
4 Фев 2010 в 17:26

2 ответа

Лучший ответ

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

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

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

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

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

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

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

2
Will Hartung 4 Фев 2010 в 04:53

Из CouchDB: полное руководство:

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

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

2
cloudhead 4 Фев 2010 в 04:32