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

http://tftf.ru/stati/orientdb/ - основные проблемы и решения. Очень полезный FAQ.


1. Если кто-то юзал, расскажите как полёт, какие косяки и т.д.

2. База дружит с js, а с php только через левый бинарный драйвер? https://github.com/AntonTerekhov/OrientDB-PHP

3. Вытекает из 2. Сервер лучше поднять io.js, нежели возиться с php?

Понимаю, что не по адресу, но php уже достало и хотелось бы сократить его участие до минимума. Хочу запустить соцсеть и mysql для этого плохо подходит.

Как у OrientDB и io.js со стабильностью или лучше пока на mongoDB и node.js?

Gozar,
Хотел попробовать, да вот только у меня пока на жабу аллергия. Кобеззза вроде бы положительные отзывы давал.

А чем mysql не подходит? Нужны динамичные(или как так их звать?) структуры для хранения данных? Так они в том же PostgreSQL есть. Если честно, то Постгре ещё не пробовал, но в анонсах говорилось, что она обгоняет Монго.

Как бы я не любил(со вчерашнего дня, хах) io.js, но оно ещё нестабильно, об этом даже на главной написано. Так что для серьёзных проектов взял бы Ноду&Монго.

Poznakomlus,
Исправил тебя, бро.

Safort,
Нужны минимум графы, а документы + графы очень заманчиво, поэтому OrientDB. Я не буду её использовать, только если есть жуткие косяки. Если вы их не знает идите нафиг из темы.

Масштабировать предлагаешь только вертикально? Чёта стрёмная идея.

ЖиШи: У меня уже запилена соц сеть на php+mysql и mysql подходит для этого дела как вертолету пропеллер снизу. На одну страничку 7 таблиц. Страшно представить когда юзеров будет десятки тысяч. Про расширяемость даже сказать страшно.

вроде ж масштабируется уже? нужно закопаться, а то проект на ней делаю )

melky,
Ты как графы хранишь, отдельной табличкой?
http://www.linux.org.ru/forum/web-development/9909010

Я бы не рыпался, если бы мне не было жизненно необходимо иметь графы.

Мне масштабируемость сейчас нужна больше приложения, нежели количество пользователей и машин. А у меня уже каша из таблиц с названиями:

car_theme
car_runner
car_winner

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

Кто хочет поговорить, прочитайте сначала пожалуйста "NoSQL. Новая методология разработки нереляционных баз данных" хотя бы полкнижки и попробуйте OrientDB. А то разговор не клеиться из-за того, что вы не понимаете о чем он.

ну да ... по нормальным формам прошёлся
можно было бы и в текущем проекте графоориентированную БД заюзать, уж больно интересная

Чем OrientDB мне больше MongoDB нравится:

1) В MongoDB дурацкий язык запросов, а в OrientDB SQL-like;
2) В MongoDB атомарность только на уровне отдельного запроса и если нужны транзакции, то идёт пляска с findAndModify, а в OrientDB есть поддержка ACID транзакций;
3) MongoDB чисто-документно ориентированная СУБД, и для графов приходится заюзывать отдельно графовую СУБД (например, Neo4J), а OrientDB документы + графы.

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

Я пока сам Orient не пробывал, но попробую точно, уж больно много плюшек.

Я как раз сейчас. :)

для linux:
Если установлена java, то просто распаковываешь архив и: sh ./server.sh

В комплекте админка (http://localhost:2480/), чуть-чуть похожа на phpmyadmin, есть графическая утилита (кавайная) для визуализации связей.

Да, да, очень зацепило. :)

db огонь.

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

select id, name, out('Type') as type, chain('Thematic') as thematic from Star where id=2015
{
id:2015, name:'Bada', type:'Big', thematic:[{
  id:101, 
  name: 'bla'
},
{
  id:102, 
  name: 'blu'
}]
}

А не то, что сейчас:

select id, name, out('Type') as type, out('Thematic').id as th_id, out('Thematic').name as th_name from Star where id=2015
{
id:2015, name:'Bada', type:'Big', th_id:[101, 102], th_name: ['bla', 'blu']
}

Целая миллисекунда нужна на пересборку в объект. :(

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

п.с.: отдаю своё предпочтение PostgreSQL (юзаю phpPgAdmin, хотя пишу на nodejs)

Что ты хранишь списком? А зачем тебе БД. Просто храни гигантский JSON в памяти, если у тебя её конечно хватит...

Если у тебя БД будет метров на 300-500-1000-терабайт, тоже будешь все рекурсивным методом обрабатывать на клиенте? :D

Приведи пример, как ты сделаешь тоже что я привел выше с помощью одного запроса

ORDER BY, WHERE, INDEX и тп самому пилить?



сферический пример в вакууме намбо уан:
Есть каталог товаров. Нужно хранить/отображать(типа навигация, разворачивающийся список) структуру категорий.
Ну сколько их? Ну 300. Достал все из БД и строй дерево жабаскриптом на клиенте.
Не 300 а 5000000000? Ну подгружай по уровням. Да, нудно вводить понятие уровня, нумеровать их при переносе одной категории в другую и тп, но это всё дело не хитрое.


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

это конечно было бы здорово, но когда то нужно и мозгом думать

Я тебе сейчас опишу задачу, чтобы не пытаться разобрать твой бред.

Задача:

Есть БД пользователей, у пользователей есть чуть более чем 100500 разных характеристик, интересов и т.д. 
Имеем Пользователя с динамическим количеством 100500 параметров(каждый из это список ссылок на отдельную "таблицу" или "класс" или внутренняя ссылка на другое поле той же "таблицы").

Какие ещё динамические подгрузки, какие ещё категории?! Если ты не сможешь выбирать пользователя и связанно с ним подгружать выборки из этих 100500 параметров, то ты получишь ад. Самый натуральный, не выдуманный, а АДСКИЙ ад. Через 5-10 параметров, которые ты осилишь своими так называемыми списками ты получишь код работающий 1-2-3-10 секунд...

Даже если ты супер-пупер программист и проектировал 10 лет базы данных, а я их проектировал, т.к. у меня в мускуле аж 2 вида связей: списки смежности и граф на 5 внешних параметров.

Я не пишу на Postgree не потому, что мне взападло, а потому что она не может то, что мне нужно. Не умеет. Если умеет, то я тебя прошу покажи!

Создай 5 пользователей с 10 частично-разными наборами характеристик, а затем свяжи их вместе и покажи, что у тебя получится.

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

ORM в хайлоад? фига! о_0

Кто не в теме, подумает что это не в тему, но мне почему то вспомнилось:

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

не исключено, есть много всего что не каждому придёт в голову. не всегда хорошего


половина из них - просто значение ни на кого не ссылающееся


Например интересы юзера? Ты суёшь номера из таблицы с их расшифровкой в одно поле? Ты не умеешь проектировать БД. Тебе нужно 3 таблицы: юзеры, расшифровки, связи_юзеров_с_расшифровка� �и. Не забудь про индексы.

2 таблицы, я буду с тобой называть все таблицами. Ты похоже по другому не понимаешь.
Юзеры и расшифровки, для связей таблица не нужна.
Слив засчитан. :nono:

Наркаманские вбросы оставь для детсада.

Просто признайся что ты сразу не подумал и теперь не хочешь переделывать. Обещаю долго не гнобить.

Я тебя сейчас окончательно зачморю, за то, что ты не хочешь думать. Слабо написать БД для сайта состоящую из 1 таблицы с фиксированным количеством полей и не нагрузить выборки при росте связей и полей? Только кирпичами не сри. На orient такое вполне возможно. Жду не дождусь когда ты на Postgree подобное предложишь. ;)

это случаем не оно?
http://www.postgresql.org/docs/9.1/s...aggregate.html

Понятия не имею.
Напиши запрос и то, что он возвращает.

Чёт у меня затык с тем чтобы связанные записи получить. Кст, кто какой модуль использует? :)

на первую часть отвечу сам.

db
  .select('*, out_.in.fname as fname, out_.in.lname as lname, out_.in.photo_50 as photo')
  .from('Post')
  .transform(function (record) {
    record.fname = record.fname[0];
    record.lname = record.lname[0];
    record.photo = record.photo[0];
    delete record._out;
    return record;
  })
  .order('time desc')
  .limit(10)
  .all()
  .then(function (results){

и ещё вопрос в догонку. про автоинкремент и транзакции в orientDB кто нибудь слышал?

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.