Сортировка ключей во view в Couchbase делается case insensitive
А точнее, сортировка строковых ключей делается без учета регистра, но с учетом Unicode Collation Algorithm.
Документация говорит в точности следующее:
Here are the exact rules for sorting (collation) of keys. The most significant factor is the key's object type; keys of one type always sort before or after keys of a different type. This list gives the types in order, and states how objects of that type are compared:
Что это нам дает? Например, при переборе элементов по диапазонам ключей можно рассматривать только половину символов из множества [a-zA-Z], а с учетом того, что выбор элементов по диапазону номеров не эффективен, это может дополнительно ускорить перебор больших результатов во view. О чем речь? Сейчас поясню.
Индекс для view в Couchbase представляет из себя двоичное дерево, поэтому чтобы выбрать диапазон с #0 по #10000, например, внутренней кухне кауча придется сначала пройти дерево в глубину до номера 9999. И когда мы захотим выбрать элементы с #1'000'000 по #2'000'000, каучу придется пройти всё дерево с нуля до двух миллионов минус один. Это очень медленно. А на практике, еще и соединения отваливаются по таймауту после первой минуты. В общем, перебирать по номерам -- не лучшая идея, если у вас большой view. К тому же, реализация клиентского API для node.js, которой я пользовался, предпочитает прочитать весь диапазон в память, из-за чего падает при переходе через 2ГБ. Не слишком понятно, в каком месте падает, т.к. нода 64-битная, и подозрение ложится на libcouchbase, но это всё детали, а главное: если view не влезает в память вашей машины, то читать его нужно диапазонами ключей, т.е. с "doc_bar" по "doc_foo", например.
Документация говорит в точности следующее:
Here are the exact rules for sorting (collation) of keys. The most significant factor is the key's object type; keys of one type always sort before or after keys of a different type. This list gives the types in order, and states how objects of that type are compared:
- null
- false, true (in that order)
- Numbers, in numeric order of course
- Strings, case-insensitive. The exact ordering is specified by the Unicode Collation Algorithm. This is not the same as ASCII ordering, so the results might surprise you -- for example, all symbols, including "~", sort before alphanumeric characters.
- Arrays, compared item-by-item as described above.
- Maps/dictionaries, also compared item-by-item. Unfortunately the order of items is ambiguous (since JSON doesn't specify any ordering of keys, and most implementations use hash tables which randomize the order) so using these as keys isn't recommended.
Что это нам дает? Например, при переборе элементов по диапазонам ключей можно рассматривать только половину символов из множества [a-zA-Z], а с учетом того, что выбор элементов по диапазону номеров не эффективен, это может дополнительно ускорить перебор больших результатов во view. О чем речь? Сейчас поясню.
Индекс для view в Couchbase представляет из себя двоичное дерево, поэтому чтобы выбрать диапазон с #0 по #10000, например, внутренней кухне кауча придется сначала пройти дерево в глубину до номера 9999. И когда мы захотим выбрать элементы с #1'000'000 по #2'000'000, каучу придется пройти всё дерево с нуля до двух миллионов минус один. Это очень медленно. А на практике, еще и соединения отваливаются по таймауту после первой минуты. В общем, перебирать по номерам -- не лучшая идея, если у вас большой view. К тому же, реализация клиентского API для node.js, которой я пользовался, предпочитает прочитать весь диапазон в память, из-за чего падает при переходе через 2ГБ. Не слишком понятно, в каком месте падает, т.к. нода 64-битная, и подозрение ложится на libcouchbase, но это всё детали, а главное: если view не влезает в память вашей машины, то читать его нужно диапазонами ключей, т.е. с "doc_bar" по "doc_foo", например.