|
2.2, nc (ok), 23:02, 18/05/2016 [^] [^^] [^^^] [ответить]
| +4 +/– |
У меня другая проблема - хочется попользовать, но не могу придумать куда))
| |
|
3.3, A.Stahl (ok), 23:10, 18/05/2016 [^] [^^] [^^^] [ответить]
| +/– |
Ну, ты можешь хранить там имя соседской кошки. И свой возраст. И текст любимой песни. Вот.
| |
3.4, Аноним (-), 00:16, 19/05/2016 [^] [^^] [^^^] [ответить]
| –2 +/– |
Основное отличие - динамическая возможность создать структуру таблиц И связи между ними.
| |
|
4.5, Аноним (-), 01:10, 19/05/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
А типа на том же посгре я не могу динамически создать таблицу/отношение, угу, tell me moar. Или что имелось в виду?
| |
|
5.32, Аноним (-), 18:03, 21/05/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
> А типа на том же посгре я не могу динамически создать таблицу/отношение,
> угу, tell me moar. Или что имелось в виду?
на посгре нет, не можешь.
| |
|
|
3.11, Лютый жабист (ok), 06:53, 19/05/2016 [^] [^^] [^^^] [ответить]
| –2 +/– |
Хорошо вписывается задача - работать с дампом какой-нибудь соцсети.
Например скачал весь вконтактик: друзья, группы. json, среднеструктурированный.
В SQL-ях такое хранить вообще боль.
В Mongo самих пользователей - очень удобно, но со связями работает медленно. А тут самое оно.
| |
|
4.17, АнонимУася (?), 21:55, 19/05/2016 [^] [^^] [^^^] [ответить]
| –2 +/– |
>В SQL-ях такое хранить вообще боль.
Ты наверное хотел сказать: "в реляционных субд"?
Так и тут ты не прав. Просто связи приходится проектировать заранее. Это плата за функциональность, недоступную в сетевых БД.
| |
|
5.22, Лютый жабист (ok), 05:27, 20/05/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
"связи приходится проектировать заранее"
Сложно проектировать заранее то, что не ты проектируешь. Я же написал про дамп соцсети. Ну и проектируй, не проектируй, в SQLщине у тебя будет страшенная куча таблиц, а в document based nosql - всё в одну коллекцию красиво залезет.
Это и есть "В SQL-ях такое хранить вообще боль"
| |
|
6.35, АнонимУася (?), 11:48, 24/05/2016 [^] [^^] [^^^] [ответить]
| +/– |
> "связи приходится проектировать заранее"
> Сложно проектировать заранее то, что не ты проектируешь. Я же написал про
> дамп соцсети. Ну и проектируй, не проектируй, в SQLщине у тебя
> будет страшенная куча таблиц, а в document based nosql - всё
> в одну коллекцию красиво залезет.
> Это и есть "В SQL-ях такое хранить вообще боль"
Спроектирую структуру для твоего дампа. За деньги. Заранее определи отчеты, которые хочешь получать, сделаю так, что связи будут вычисляться со вполне сравнимым временем. За деньги хрен с ним, пусть сообщество решит, стоит мне в итоге платить, или нет. Ждать от тебя дамп?
| |
6.36, dlazerka (ok), 19:23, 25/05/2016 [^] [^^] [^^^] [ответить]
| +/– |
> Сложно проектировать заранее то, что не ты проектируешь. Я же написал про
> дамп соцсети. Ну и проектируй, не проектируй, в SQLщине у тебя
> будет страшенная куча таблиц, а в document based nosql - всё
> в одну коллекцию красиво залезет.
> Это и есть "В SQL-ях такое хранить вообще боль"
У информации должна быть структура, иначе это энтропический шум. Хранить входные данные "как есть" имеет смысл только если их не надо обрабатывать, а так же выдавать "как есть". И "в SQLях" такое прекрасно хранится в столбце типа TEXT или BLOB.
Хотя в PostgreSQL можно юзать тип JSONB, который и процессить можно быстро (быстрее чем Монга, замерял), и индексы строить по JSON-овским полям, и JOINы делать.
А если же данные нужно каким-то образом обрабатывать, то в любом случае нужно знать структуру, хотя бы интересующую часть. То есть в schema-less базах схему тоже нужно менеджить, но уже в нашем собственном коде, а не в СУБД: писать руками db-upgrader скрипты. И если наш data source поменял формат, то и наш код тоже нужно менять.
Schema-less -- это отсутствие фичи. Храните всё в одном столбце TEXT, BLOB или JSONB и будет вам schema-less, вполне подходящее решение для определённых случаев, никто не заставляет нормализовать.
| |
|
|
|
|
2.9, Игорт (?), 06:17, 19/05/2016 [^] [^^] [^^^] [ответить]
| +6 +/– |
Были и еще какие. Гугли на английском orientdb shit или orient kill startup, таких историй начитаешься - волосы дыбом. Вот например мы столкнулись с таки багом - делаешь select с order by - все хорошо, добавляешь limit x - выбирает любые x записей и сортирует только их. И еще, если разрабы говорят, что баг починен - не верь, проверяй - врут безмерно.
| |
|
3.10, Это я (?), 06:37, 19/05/2016 [^] [^^] [^^^] [ответить]
| –3 +/– |
[quote]делаешь select с order by - все хорошо, добавляешь limit x - выбирает любые x записей и сортирует только их.[/quote]
Наверное, это для повышения производительности...
| |
3.26, OramahMaalhur (ok), 11:11, 20/05/2016 [^] [^^] [^^^] [ответить]
| +2 +/– |
Про разрабов — это правда. Они, возможно, что-то и починили, а может и нет. А может ещё и поломали по соседству. Но всегда заявляют, что починили.
В своё время полтора года назад замахались тестировать их фиксы кластера.
| |
|
2.25, OramahMaalhur (ok), 11:08, 20/05/2016 [^] [^^] [^^^] [ответить]
| +2 +/– |
Было полно проблем с 2.0. Оно сначала тупо не работало в кластере (ни документ, ни граф), потом работало только в 2-хнодовом режиме, но не работало в 3+.
Но вполне возможно, что уже починили.
| |
|
1.7, Анон вроде (?), 02:55, 19/05/2016 [ответить] [﹢﹢﹢] [ · · · ]
| –6 +/– |
А когда успели придумать новое слово "Графовые СУБД"? Раньше их всегда сетевыми звали.
| |
|
|
3.18, Аноним (-), 23:02, 19/05/2016 [^] [^^] [^^^] [ответить]
| +/– |
ага. графовые - частный случай иерархических(или наоборот, как смотреть ;)
| |
|
|
1.13, dlazerka (ok), 09:49, 19/05/2016 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Она distributed? Нигде не могу найти про это, только упоминают про Big Data. Хотя я работал с big data, и там подразумевается, что данные никак не помещаются на одну машину. Или они просто ради маркетинга используют термин big data?
| |
|
2.14, ttt (??), 10:28, 19/05/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
orientdb - распределенная
neo4j - не распределенная
| |
|
3.19, Аноним (-), 23:04, 19/05/2016 [^] [^^] [^^^] [ответить]
| +/– |
> orientdb - распределенная
> neo4j - не распределенная
я бы не относил сабж к распределенным всерьез. поддержка мультимастре репликации - еще не делает что-то "распределенным" само по себе ;)
а вот наличие ACID - уже ощутимый плюс на фоне сонма безликих, бесполезных аналогов, лишенного оного.
| |
|
4.20, dlazerka (ok), 00:52, 20/05/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
> я бы не относил сабж к распределенным всерьез. поддержка мультимастре репликации -
> еще не делает что-то "распределенным" само по себе ;)
> а вот наличие ACID - уже ощутимый плюс на фоне сонма безликих,
> бесполезных аналогов, лишенного оного.
Хм, а в чём тогда настоящая "распределённость", если не в мультимастере?
| |
|
5.27, Аноним (-), 11:14, 20/05/2016 [^] [^^] [^^^] [ответить]
| +/– |
в "распределенности" обработки, сюрприз. безо всяких "мастеров" с полностью асинхронной обработкой без точек отказов или узких мест в других смыслах(не исключая производительность).
ваш КО.
| |
|
|
|
|
|
2.16, default (??), 17:07, 19/05/2016 [^] [^^] [^^^] [ответить]
| –2 +/– |
Интересная новость... "Код OrientDB написан на языке Java..." И до свидания! :)
| |
|
3.21, dlazerka (ok), 00:57, 20/05/2016 [^] [^^] [^^^] [ответить]
| +/– |
> Интересная новость... "Код OrientDB написан на языке Java..." И до свидания! :)
Чу! Мне послышался треск, как будто что-то рвётся.
| |
3.23, Лютый жабист (ok), 05:29, 20/05/2016 [^] [^^] [^^^] [ответить]
| +/– |
> Интересная новость... "Код OrientDB написан на языке Java..." И до свидания! :)
Всё bigdata написано на жабе, не нравится, можешь остановить планету и сойти.
| |
|
|
5.29, Вареник (?), 02:11, 21/05/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
Постгрес лучшая DB, пока данные еще влезают на одну машину и IO еще успевает их пропускать.
| |
|
6.31, dlazerka (ok), 05:28, 21/05/2016 [^] [^^] [^^^] [ответить]
| +/– |
> Постгрес лучшая DB, пока данные еще влезают на одну машину и IO
> еще успевает их пропускать.
+1
А если не влазят, то лучше не заниматься БД самим, а использовать сервисы от GCP или AWS.
| |
|
|
4.28, Аноним (-), 11:16, 20/05/2016 [^] [^^] [^^^] [ответить]
| +/– |
>> Интересная новость... "Код OrientDB написан на языке Java..." И до свидания! :)
> Всё bigdata написано на жабе, не нравится, можешь остановить планету и сойти.
бидата и жаба в оном предложении - заводомый когнитвный диссонанс.
даже иерархические БД там носят вторичный характер и использутся сугубо для оперативной аналитики а основная обработка идет в Распределенных бд.
ортодоскальные вещи - не масштабируются так хорошо и не расшмиряются функционально так(не без исключений, не меняющих ничего принципиально, конечно).
| |
|
3.30, Вареник (?), 02:14, 21/05/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Интересная новость... "Код OrientDB написан на языке Java..." И до свидания! :)
Значит ты не попадаешь в мир кластеров и BigData. Вырастешь - может быть сможешь вернуться.
| |
|
|
|