db.select().from('TestUsers').where({name: 'be398b84d8894456 1427375950809'})

Ну понятное дело, что он будет медленнее работать :) Это же полнотекстовый индекс, а если тебе нужен супер быстрый доступ, то Hash.

unique_hash_index? Сам отвечу. Да. :) 38 ms

db.select().from('TestUsers').where({name: 'be398b84d8894456 1427375950809'})

Ну unique или не unique это уже от твоей задачи зависит, но hash :) Я прост всё с ориент ещё не работал, поэтому говорю в терминах других СУБД.

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

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

Ну просто fulltext для других задач.

Хз куда это пригодиться, но спасибо запомню. Мне нужен будет поиск по тэгам. Думал оставить мысли о нем на потом, но видать судьба :)

Кстати ты не в курсе, как бы лучше по тегам базу построить? Типа как на youtube

Нез :)

Поиграйся ещё с составными индексами (если ещё этого не делал), т.к. это супер мощная штука.

Наверное стоит создать одну таблицу тегов, а от документа кинуть на них грани? Тормоза только при создании(добавлении нового тэга и связывании документа с тегами через грани), дальше выборка должна быть быстрой :)

Зависит от организации тегов. Если как в Amazon-е анализируется статистика и показывается реклама в зависимости от неё, то самое оптимальное использовать граф (тем более в Ориент он из коробки), а если простая система тегов аля твиттер, то простая коллекция с хеш-индексом.

Однозначно граф.

kobezzza,
Выше написал, ты успел перелистнуть.

Да, норм.

Ещё раз спасибо за пояснения, мне работать пора :D

Нез, обращайся :)

мне всё больше начинает нравиться. на мой вкус это очень удобно


вау, можно писать свой функции

.query('update (select expand( in() ) from Test where @rid = ' + gid + ') set status = testFn(outcome)')

Хочу добавить своё WOW!

OrientDB рвёт MySQL как грелку :D Страшные JOIN-ы превращаются в приятные выборки, там где 9 строчные mysql запросы превращаются в понятные 3 строчные. Хочу забыть мускул как страшный сон.

Честно говоря если для получения нового значения нужно создать транзакцию update+select, то никак по другому как ручной, такой автоинкремент не назвать. Другого же способа создать autoincrement я не нашёл. Возможно в будущем добавят функцию, что очень желательно, но пока только связка вручную (транзакцию update+select).

В многих NOSQL СУБД есть для таких задач selectAndUpdate / selectAndRemove, в Orient такого нет? Просто транзакции это из пушки по воробьям в таком кейзе и сильно ударит по производительности запроса.

http://www.orientechnologies.com/doc...l#sql---update

Смотреть return :)

kobezzza,
Ага, спасибо помогло, на 1 запрос меньше.

А директивы запроса регистрозависимые или нет? Просто следуя примерам в их доке, то как то так:

RETURN AFTER

Мб поможет

http://stackoverflow.com/questions/2...-increment-var

Всегда пожалуйста :)

.counter лишнее.

counter INCREMENT value = 1 return after $current

Надеюсь в будущем добавят всё таки функцию типа inc() или ключ как в мускуле.

Напиши таск разработчикам :)

kobezzza,
знаешь как вставлять в ориент (vertex, edges) типа такого: mysql insert if not exist?

Не знаю, я пока не юзал Ориент, т.к. на работе Монга :)

kobezzza,
Ага! Вот ты и попался) Это как чуваки, которые рьяно выступают за io.js, а у самих Node.js установлен)

:D

Кстати нашёл забавную прогу 0xDBE. Только жаль, что там нет Orient-а.

http://tftf.ru/stati/orientdb/ Неочевидное и невероятное.

Сначала разместил на хабре, но у них какие-то свои скрепы, только их модерам понятные. Поэтому, буду пополнять тут. http://tftf.ru/stati/orientdb/

Особенно полезно начинающим. Самые популярные проблемы при старте работы с OrientDB.

Gozar,
спасибо, Гозарыч)

Всегда пожалуйста. :)