........... OrientDB ...........

[Zend]

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

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

[Gozar]

Всё равно изврат какой то с ID-шниками

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

[Zend]

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

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

1. Built for Speed

OrientDB was engineered from the ground up with performance as a key specification. It’s fast on both read and write operations. On writes, it can store up to 150,000 records per second*. The OrientDB time series module can insert 120,000 records per second*, while keeping the time graph synchronized for real-time analytics.

[kobezzza]

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

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

А вот с автоинкрементом не всё понятно.

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

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

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

[Gozar]

Нашёл данные что в запросах с LIKE ориэнт сливает мускулю в 2 раза. Ну это как бы и понятно, не для LIKE его делали.

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 ребер)).

что если сравнить связи в ориэнс с JOIN-ами в мускуле.

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

Вручную никогда нельзя делать автоинкремент.

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

[kobezzza]

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

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

[Gozar]

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

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

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

А, ты про это.

[kobezzza]

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

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

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

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

[Gozar]

Это оптимизация на спичках

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

то если построен индекс,

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

/profile/kobezzza

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

[kobezzza]

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

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

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

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