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

пс2: Логин и ник у меня сейчас совпадают. Я считаю это удобным.

Ты знаешь как работают индексы?
Очень схематично:

var myTable = {
  id_1: {
    name: 'kobezzza',
    value: 1
  },

  id_2: {
    name: 'gozar',
    value: 2
  }
}

id_1 и id_2 здесь первичные индексы.
Построим вторичный индекс по name

var myIndex = {
  kobezzza: myTable.id_1,
  gozar: myTable.id_2
}

Таким образом теперь запрос по name будет идти в индекс, который без каких либо итераций сразу вернёт нужное поле (в теории алгоритмов - это логарифмическая сложность, см график натурального логарифма).
Понятное дело что это очень схематичное описание.

То, что ты не понимаешь этого, но стоишь на своём не делает тебе чести. Я не делал никаких бенчмарков в Ориент, но я прочитал много книг про механизмы работы СУБД и в частности индексы и имею неплохой практический опыт в этом. Дело в том что организация индексов очень похожа в большинстве СУБД, и я уверен, что в Orient она такая же.

Сейчас похоже, что ты просто хочешь выиграть спор, который сам же и начал любой ценой, но я и не хочу с тобой спорить. Все мы можем ошибаться и в данном случае ты очевидно не прав, т.к. мои слова подтвердит тебе любая статья / книга про устройства СУБД.

Знаешь почему у тебя поиск по инкрементальному числу без индексов делается быстро? Потому что у тебя данные лежат в безразрывной последовательной области памяти (на диске и в оперативе), и поэтому Ориент может приминить самостоятельную оптимизацию, но как только ты устранишь это условие, например, при сегментации или фрагментации данных, то вопрос создания индекса встанет очень остро, а создавать индексы для уже созданой коллекции задача реально геморойная, т.к. придётся либо на время залочить БД, либо делать фоном съедая часть ресурсов системы.

Ты привязался к индексам и скорее сам споришь, хотя я не понимаю зачем. Я находясь в здравом уме понимаю, что индексы ускоряют доступ. Не нужно писать ещё одну страницу с объяснением очевидного.

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

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

Пойду сделаю бенчмарк :)

Конечно, каждый индекс - это дополнительное место на жестком диске и в оперативной памяти (ведь для нормальной работы БД она должна полностью влезать в оперативу). Если памяти не хватает, а возможности сегментировать БД нет, то некоторые СУБД могут загружать в оперативу только индексы, а за данными ходить на хард (или как вариант загружать в оперативу только часть данных, но индексы обязательно или будут неменуемые тормоза).

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

Но так или иначе, если база перестаёт влезать в оперативу, то самое лучшее решение - это сегментация, т.е. разнесение данных на разные машины. Некоторые СУБД могут делать это сами, в некоторых придётся писать руками (и это реальный геморой).

Я был на мастер классе от TopFace (они юзают MySQL + Redis) и они не используют встроенные индексы, а на каждый популярный запрос сохраняют результат в отдельную таблицу, т.е. делают индексы руками, а сами таблицы размазывают по кластеру по географической позиции, т.е. пользователи из Москвы на одних серверах, из Питера на других и т.д. Причём само размазывание у них тоже написано самостоятельно и там жесть логики.

Но если база данных становится очччень большой (свыше терабайта), то тут вступает в игру техника работы с BigData, а именное map-reduce, например, есть мега фреймворк Hadoop для таких задач.

В общем проектирование БД это реально очень сложная задача.

на 30000 записей рандом строк
db.select().from('TestUsers').containsText({name: '81a3dc206632202c51851460da2df473e61215c0'})
unique SBTREE 234ms

db.select().from('TestUsers').where({name: '81a3dc206632202c51851460da2df473e61215c0'})
unique SBTREE 40ms

db.select().from('TestUsers').containsText({name: '81a3dc206632202c51851460da2df473e61215c0'})
fulltext SBTREE 38ms

db.select().from('TestUsers').containsText({name: '81a3dc206632202c51851460da2df473e61215c0'})
fulltext LUCENE 230ms
db.select().from('TestUsers').where({name: '81a3dc206632202c51851460da2df473e61215c0'})
fulltext LUCENE 40ms

Вот такая загогулина, нужно ещё и правильные выборки делать.

Ты тестил полнотекстовый поиск? Там не всё так просто :) Я хз позволяет ли Ориент задать гибкую настройку такого индекса, но вообще там куча настроек (см. доку LUCENE или Elastic) и полнотекстовые индексы это вообще отдельный мир, именно поэтому это делают отдельные инструменты :)

Плюсы LUCENE:
Скорость создания индексов просто молниеносная по сравнению с SBTREE,
Занимаемое на HDD место тоже минимум в 2 раза меньше (SBTREE 200mb, LUCENE 40mb)

Я тестил:
1. полнотекстовый
2. where =
Т.к. по полю создан индекс, то where логично должно быть быстрее, ты же сам писал табличка и всё такое...

По умолчанию кстати создается SBTREE