On 11.05.2016 19:29, "Иль" wrote: > Не нужны тебе транзакции — ты о > них и не задумываешься. Хотя в СУБД они есть, ждут своего часа.
Зато уж когда час их настанет, как выскачут из-за угла, да как врежут со
всей дури ничего не подозревавшему о connection.setAutoCommit(false)
программисту по йайцам. И возопит он весьма громко.
Здравствуйте, gandjustas, Вы писали:
G>>>Скорее наоборот. С бекапами у NoSQL обычно проблема, обслуживание часто требует остановки сервиса. C>>ЩИТО? G>Напомни какая NoSQL база может делать дифференциальный бекап и Point In Time restore на базе в минимум в 200гб?
Cassandra ( https://docs.datastax.com/en/cassandra/2.0/cassandra/operations/ops_backup_incremental_t.html ), Riak (стандартной репликацией) — точно.
G>Сколько монге надо времени на сбор индексов после рестора 100 гб базы?
Секунды?
Здравствуйте, Alex.Che, Вы писали:
B>>> Для каких задач можно получить преимущества от Graph или Column oriented хранилищ? >> Аналитика
AC>Аналитика чего именно?
Агрегированные запросы (суммировать все строки, у которых такие-то значения) на поколоночных базах работает быстро. Они для этого и существуют, в OLTP системах их не используют
опа опа мы воюем с нато
любит хавать этот кал
путинская вата
> Агрегированные запросы (суммировать все строки, у которых такие-то значения) на поколоночных базах работает быстро. > Они для этого и существуют, в OLTP системах их не используют
для подобного рода аналитики обычно используют OLAP-серверы/сервисы.
Здравствуйте, Alex.Che, Вы писали:
>> Агрегированные запросы (суммировать все строки, у которых такие-то значения) на поколоночных базах работает быстро. >> Они для этого и существуют, в OLTP системах их не используют
AC>для подобного рода аналитики обычно используют OLAP-серверы/сервисы.
ОЛАП — это построитель сводных таблиц с данными из хранилища данных. В сводных таблицах часто лежат агрегированные данные, например сумма по уровням измерений. Некоторые хранилища данных как раз и используют механизм поколоночного хранения, чтобы быстро выполнялись агрегированные запросы, необходимые ОЛАПу.
Это я вам говорю как заслуженный разработчик олапов и хранилищ данных
опа опа мы воюем с нато
любит хавать этот кал
путинская вата
Разверни свою мысль, "не совсем" что именно? А то по ссылке описывается обычное разгильдяйство и пренебрежение базовыми принципами обеспечения безопасности, которые к монге не имеют никакого отношения.
... в первом классе мне говорили, что нужно делиться, а теперь говорят, что это незаконно ...
> Сколько-то лет назад, когда я пересекался с ИнтерСистемс, > влезть в базу Cashe можно было только их собственным инструментом. Онли. > Это по сю пору так?
Здравствуйте, gandjustas, Вы писали:
B>>Для каких задач можно получить преимущества от Graph или Column oriented хранилищ? G>Графовые базы кроме получения объекта по ключу умеют делать обход графа на уровне движка. И говорят это быстрее чем CTE\connect by в РСУБД.
Я проводил эксперименты с графовыми базами данных. В частности на Neo4j — самой популярной графовой бд. В итоге там очень выразительный язык запросов — cypher. Оч. понравился, по скорости далеко не все так радужно, залил часть боевой базы — в сравнении с SQL сервером до 10 раз медленнее запросы выполняются, как я не пытался ускорить. Плюс средства диагностики плохо развиты, не понятно что происходит под капотом. Говорил с командой, которая ее использует в своем проекте — аналогичное мнение.
>> Сколько-то лет назад, когда я пересекался с ИнтерСистемс, >> влезть в базу Cashe можно было только их собственным инструментом. Онли. >> Это по сю пору так? AC>есть odbc и jdbc
да толку то...
у них теперь даже SQL поддерживается, в какой-то мере.
примерно как у BDE(IDAPI)
по уверениям продавцов каши, всё даже аж "летает".
только низенько-низенько.
в хорошую погоду.
если пнуть с горы...
Здравствуйте, Иль, Вы писали:
Иль>Есть ощущение что вы "накушались" с MySQL, а не с RDBMS. Мы тоже накушались MySQL по самое не балуйся. Но переход на настоящую RDBMS и правильную работу с ней решает вопрос.
Здравствуйте, teoreteg, Вы писали:
T>Здравствуйте, Иль, Вы писали:
Иль>>Есть ощущение что вы "накушались" с MySQL, а не с RDBMS. Мы тоже накушались MySQL по самое не балуйся. Но переход на настоящую RDBMS и правильную работу с ней решает вопрос.
T>Правильные это какие? И чем так уж плох мускуль?
Правильная работа.
Плох тем, что не подходит для нагруженных систем. Например нет поддерживает индексы по условию, оконные функции, CTE, гораздо хуже ситуация с обслуживанием (по сути не приспособлен для работы 24x7 в сколь бы то ни было серьёзных проектах) и т. д. и т. п.
Но вообще если вы никогда не задумывались о перечисленном, то значит ещё не время. Просто считайте это моей субъективной оценкой.
Здравствуйте, Blazkowicz, Вы писали:
B>Привет,
B>Проект уже в каком-то виде использует свой примитивный NoSQL. Пользователи загружают свои данные в систему. Система строит отчет и хранить его в виде сериализованного объекта в файле в облаке. B>Новая задача требует собирать некоторые данные пользователей и хранить их другим объектом. Вроде как обычное Key-Value выходит. B>Сервис публичный. Есть риск что данных станет очень много. Поэтому пихать много всего в MySQL не охота. B>Транзакции особо не нужны. Нужно хранить достаточно жирные объекты до 10Мб, а в будущем может и больше.
Все будет зависеть в том числе от того, на каком языке вы пишете.
Возможно подойдет Cassandra + Spark.
B>Для каких задач можно получить преимущества от Graph или Column oriented хранилищ?
Графы для анализа связей и вообще для игр с теорией графов.
Госпади, ну почему при каждом упоминании NoSQL вспоминают CAP?
Во-первых она ни о чем, во-вторых у автора нет и никогда не будет распределенных баз. Как и у 99% пишущих про CAP.
Здравствуйте, hrensgory, Вы писали:
H>всей дури ничего не подозревавшему о connection.setAutoCommit(false) H>программисту по йайцам. И возопит он весьма громко.
Угу. Вопил. Но виновника нашел.
