Gozar,
Ага, спс, я в доке тоже уже нашёл описание.
http://www.orientechnologies.com/doc...nsactions.html

А вот с автоинкрементом не всё понятно. У меня апи, и мне нужно возвращать ид-шники записей созданных по запросу. При этом они должны быть простыми числами. Не думаю что юзеру понравится такое: "новая игра номер #12:5" Что с этим делать я хз. Можно немного извратиться и сделать что то таоке: 2125. типа первая цифра - из скольких символов состоит номер кластера, а остальные цифры - позиция. хотя скорее всего номер кластера будет всегда из 2-х цифр.... так что ещё можно упростить. И вообще может ли одна "таблица" быть на нескольких кластерах? При горизонтальном масштабировании наверное может. Всё равно изврат какой то с ID-шниками

Просто после мускула непривычно, что автоинкрементом нужно заниматься вручную :)
Я просто сделал id integer и всё, rid для внутренних нужд, id для адекватного понимания юзерами.

Ещё один не маловажный момент - скорость. Нашёл данные что в запросах с LIKE ориэнт сливает мускулю в 2 раза. Ну это как бы и понятно, не для LIKE его делали. Интересно как дела с обычными запросами. Например что если сравнить связи в ориэнс с JOIN-ами в мускуле.

Тут вроде как пишут что всё хорошо

Для Like запросов нужно использовать специальные поисковые индексы, например, ElasticSearch, который работает вместе с основной БД или снабжать Like запрос дополнительными условиями по полям, которые есть в индексе.

Автоинкремент в NoSQL делается обычно функцией inc, в MongoDB например это $inc. Вручную никогда нельзя делать автоинкремент. Также во многих ORM для NoSQL можно задать схему и указать автоинкремент. Я лично вообще не вижу смысла в создании какого-то цифрового ИД-а, т.к. для внутреннего использования есть родной ИД, а для использования пользователями можно построить дополнительный индекс, например, по имени пользователя.

Ты явно не понимаешь разницы между MySQL (хотя уж лучше Postres взять) и OrientDB. Тут не идёт сравнение лучше/хуже, а совсем другой подход к хранению, масштабированию и выборке данных и выбирать нужно исходя из своей задачи.

containstext

2001 записей в MySql
SELECT * FROM basic WHERE des LIKE '%Яблок%' LIMIT 0 , 30
54ms

2400 записей в OrientDB
db.select().from('Basic').containsText({des: 'Яблок'}).all().then(function(){});
83ms

Строение таблиц идентично, кроме того, что в Orient-овской табличке есть еще (4 типа ребра с привязками на саму себя(~1000 ребер)).

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

http://www.orientechnologies.com/doc...increment.html

По ссылке как раз таки автоматический инкремент. Вручную - это когда берёшь значение и апдейтиш на value + 1.

Не думается мне это оптимальным, особенно если разрешены имена в UTF-8 и идет вывод в адресную строку. Ко всему прочему поиск по 1000000 записей не очень нужная операция, когда её можно избежать. Могу даже дать гарантию, что поиск по цифирке будет быстрее тем больше, чем больше записей в табличке.

А, ты про это.

Это оптимизация на спичках + гораздо удобнее видеть URL в адресной строке /profile/kobezzza чем profile/1030456.

Что касается по поиску, то если построен индекс, то поиск будет одинаковой логарифмической сложности и не будет абсолютно никакой разницы число там или строка.

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

83ms на 2000 записей, против 3ms. Очевидно, что это не экономия на спичках. С учетом того, что у меня это частая операция.

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

Ну ты же в курсе что в UTF есть ещё и другие символы, кроме латиницы? А ещё когда пользователь запостит ссылку на каком-нибудь форуме на свой профиль, вот его ждет необычный сюрприз ;)

База должна уметь горизонтально масштабироваться, все остальное не критично, использование индексов - это стандарт. Если для Orient создание индекса дорогая операция (в чём я сомневаюсь), то можно использовать дополнительно Key-Value хранилище, например Redis (кстати это очень распространённое решение).

Просто ввести ограничение на использование латиницы, как сделано в VK или Facebook.