На каком основании? Ну у них латиница! Однако... Ты же в курсе, что у VK долгое время были цифирки?

Я как бы за. Я против усложнений там, где они не нужны.

http://www.orientechnologies.com/docs/last/Indexes.html
http://www.orientechnologies.com/doc...ate-Index.html

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

Есть логин: латиница и цифры (отображается в URL)
Есть ник: что угодно (отображается на сайте)

Большинство современных сайтов используют именно такой подход.

Да, и у ФБ, это было обусловлено историческими причинами, и что писали эти проекты студенты :)

Из опыта могу сказать, что на url-ы пользователям плевать и кстати передать url вида: /user/12003 проще, нежели /user/xn----7sba…d.xn--p1ai или по твоей схеме: /user/masha_rasputina

Приятно что в Orient уже из коробки есть биндинг для Lucene (это поисковый движок для полнотекстового поиска, как на нём и основан ElasticSearch).

Долгий перебор доступных nickname-ов изящное решение? Скорее оно тормозит регистрацию у адекватных, всем нужных пользователей.

Да, особенно почтовые сервисы и понятно почему.

Ты мне не объяснил причину, почему я должен запретить пользователю набирать ЛогинПароль: ВасилийПупкин тутняпароль?

Почему я должен заставить его набирать: VasiliPupkin SuperParol285 ?
Думаешь если побесить пользователя при регистрации, он проникнется добром к сервису?

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

А у пользователя в голове мне тоже нужно индекс построить, когда он будет регистрироваться и перебирать доступные никнеймы?

kobezzza,
Ты предложил ограничить. Я спросил причину. Ты ответил - так делают другие известные тебе.

Любое ограничение несет в себе негатив. Я не вижу причины почему пользователь не может выбрать себе логин и пароль в кириллице.

Логин != Никнейм.
Если логин занят, то при наборе он об этом узнает.

Из довольно частого общения с людьми я вынес, что они не понимают этих ваших url-ов, а многие не понимают слова: браузер и адресная строка. Целесообразность чпу при этом сводиться к нулю.

С индексами всё понятно. Строим там где нужно.

Какое ограничение? Если пользователю очень нравится, то он может ходить по своему ИД, но если он хочет, то может создать алиас, которым как правило служит логин.

profile/kobezzza
profile/?id=...

Раз ты учитываешь мнение адекватных пользователей, то услышь моё: мне реально очень не удобно с индексами, которые я не могу запомнить, но на всех ресурсах я kobezzza:

vk.com/kobezzza
facebook.com/kobezzza
github.com/kobezzza


***

https://github.com/babel/babel

Вот было бы лучше, если бы было:

https://github.com/idfuj45894/453jlhfskjh546 ?

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

Если тебе плевать на пользователей, можешь даже капчу ввести. Но если у тебя не 20000000 посетителей в день, то тебя это будет сильно беспокоить.

Логин в любом случае должен быть уникальным. Ещё раз: логин != ник, т.к. ник заполняется отдельно.

Твоё мнения я и так учитываю. Ты знаешь:
И таких как я и ты, у меня на ресурсе 2 будет, от силы 3 из 100000.

Но это не причина тормозить регистрацию 100000 пользователей и снижать регистрацию.

Это и не имеет отношения к обсуждению и в данном случае это не важно. Можно хоть ФИО и типаж ввести.

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

В этом и проблема. Можно логинизацию хоть по email-у проводить. Но люди путаются с капсами, кирилицами и емейлами. А для тебя почему-то самое важное это что в url написано.

Я запутался не по этому:

1) Ты сначала сказал, что используешь дополнительные числовые ИД, что они работают быстрее - Я сказал что не важно какой дополнительный ИД если построен индекс и будет работать одинаково супер быстро (это факт), а как пример привёл индекс по логину, как самое популярное решение.

2) Потом ты сказал, что создание индекса очень дорогая операция - я объяснил, что нет, более того, что по этому полю ты так и так будешь строить индекс для поиска.

3) После этого ты начал говорить об удобстве для пользователя, что меня выбило из колеи разговора.

***

Подведу итог разговора: используйте индексы, без них какое-либо сравнение производительности не имеет смысла (как например zend приводил пример LIKE по полю без индекса). Нужен LIKE - делайте полнотекстовый индекс, нужен составной запрос - делайте составной индекс, и главное думайте - слишком много индексов - тоже плохо :)

Можно про факты поподробнее. Если ты делал уже сравнение, то выложи данные. Если нет, то это разговор ни о чём.

Выборка where id=2000, работает без индексов на 80мс быстрее нежели containstext id = mylogin и разна 2мс, я даже не понимаю, нужна ли оптимизация в этом случае.

Теперь твои данные с индексами и без.

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

пс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

пс. Кстати uniq по where тоже 38ms SBTREE, обновил табличку.

Конечно. Я просто хотел подчеркнуть, что полноекстовый индекс работает немного иначе, он не делает:

var index = {
  'someText': link,
  'more text': link
};

А анализирует сам текст и строит хитрый индекс. Полнотекстовый поиск нужен, когда мы ищем не точную строку, а фразу из строки.

***

Кстати ещё нюанс: когда делается запрос, то он использует только один индекс (думаю понятно почему), поэтому если есть частый запрос, в котором участвуют несколько полей, то лучше сделать составной индекс, т.е. индекс по нескольким полям, например, как бы это выглядело, если у нас есть индекс по age->skils->country

var index = {
  22: {
    '80lvl': {
        ru: [link1, link2, link3],
        en: [link1, link2]
    },

    '90lvl': ...
  }
}

Думаю логика ясна, обращаю внимание, что порядок параметров при запросе должен совпадать с порядком полей в составном индексе.

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

+ Многие СУБД делают самостоятельно много оптимизаций, как балансирование, сортировка и т.д. как например в случае с твоими числами - это здорово, но полагаться на это нельзя.

Посмотри ElasticSearch, это надстройка над LUCENE, которая позволяет мега гибко настраивать индекс.

да, пожалуй fulltext здесь не канает, и пробелы тоже придется из ников убрать. Не круто.

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

У меня ща на работе стоит сплит MongoDB + Elastic, и если запрос типа Like, то он убегает в Elastic, а если запрос точный, то в Mongo.

Может оно и не хорошо делать ники с пробелама. Хотя если запрашивать только при логинизации фигово, но жить можно. Но в урлах уже будет тяжело 280ms на 40 тыр. пользователей это уже жутковато. Вот и ответ почему в VK и FB только латиница.

Не понял, а в чём проблема с пробелами? Ну кроме того, что в адресной строке будет Vasya+Pupkin. Хотя обычно вместо пробела используется _

скорость запроса падает с 38ms до 280ms, не смущает?

Значит ошибся при проектировании индекса просто, у тебя какой тип индекса стоит на нике? Поставь Hash.

FULLTEXT SBTREE