Начальник хочет поэкспериментировать с NoSQL на одном из проектов. Не столько для пользы проекта, а чтобы получить опыт для будущих решений, так как с RDBMS уже много чего накушались.
Обзорно читал про NoSQL, но никогда вплотную не использовал. Потратил ещё пару дней на ознакомление, но каждый раз, когда начинаю читать про конкретное решение, возникает ощущение что это не то что нужно.
Ткните, пальцем в алгоритм выбора.
Проект уже в каком-то виде использует свой примитивный NoSQL. Пользователи загружают свои данные в систему. Система строит отчет и хранить его в виде сериализованного объекта в файле в облаке.
Новая задача требует собирать некоторые данные пользователей и хранить их другим объектом. Вроде как обычное Key-Value выходит.
Сервис публичный. Есть риск что данных станет очень много. Поэтому пихать много всего в MySQL не охота.
Транзакции особо не нужны. Нужно хранить достаточно жирные объекты до 10Мб, а в будущем может и больше.
Для каких задач можно получить преимущества от Graph или Column oriented хранилищ?
Правильно ли я понимаю, что такие решения как HBase являются полностью in-memory решениями? То есть, их вообще нет смысла использовать при отсутствии кластера в десяток серверов?
Что вообще почитать обзорного?
А какие RDBMS использовали?
Сколько данных планируется (1e6, 1e9, 1e12)?
Какой общий объем будет — гигабайты, терабайты?
Какие требования к запросам — только по ключу или сложнее?
Какие требования к скорости чтения/записи?
Какие требования к надежности (можно потерять хоть все, можно потерять операции за несколько секунд и т п.)
Какие требования к HA — какой простой допустим для технических операций, какой в случае проблем с железом?
Ну вот от этого и нужно отталкиваться )
B>Привет,
B> Начальник хочет поэкспериментировать с NoSQL на одном из проектов. Не столько для пользы проекта, а чтобы получить опыт для будущих решений, так как с RDBMS уже много чего накушались.
B>Новая задача требует собирать некоторые данные пользователей и хранить их другим объектом. Вроде как обычное Key-Value выходит.
Обычное key-value — это монга. Вроде бы последний год уже не теряет данные просто так. Или postgresql с колонками типа json (надёжнее, быстрее, сложнее настраивать).
Здравствуйте, Blazkowicz, Вы писали:
B> так как с RDBMS уже много чего накушались. B> ... B> Поэтому пихать много всего в MySQL не охота.
Есть ощущение что вы "накушались" с MySQL, а не с RDBMS. Мы тоже накушались MySQL по самое не балуйся. Но переход на настоящую RDBMS и правильную работу с ней решает вопрос.
B> ... каждый раз, когда начинаю читать про конкретное решение, возникает ощущение что это не то что нужно.
Это нормально. Если вовремя не остановиться, то (по опыту "успешных" экспериментаторов) есть риск накушаться NoSQL так, что MySQL будет вспоминаться с теплотой.
Здравствуйте, Иль, Вы писали:
Иль>Есть ощущение что вы "накушались" с MySQL, а не с RDBMS. Мы тоже накушались MySQL по самое не балуйся. Но переход на настоящую RDBMS и правильную работу с ней решает вопрос.
А так же с Oracle, SQL Server и, особенно, Firebird.
Иль>Это нормально. Если вовремя не остановиться, то (по опыту "успешных" экспериментаторов) есть риск накушаться NoSQL так, что MySQL будет вспоминаться с теплотой.
Это и моя позиция тоже. Но начальник хочет. А я не против набраться опыта на этом поприще.
Здравствуйте, Alex.Che, Вы писали:
>> Начальник хочет поэкспериментировать с NoSQL на одном из проектов. AC>научная организация?
Нет. Небольшой, относительно успешный стартап.
Здравствуйте, Blazkowicz, Вы писали:
B>Проект уже в каком-то виде использует свой примитивный NoSQL. Пользователи загружают свои данные в систему. Система строит отчет и хранить его в виде сериализованного объекта в файле в облаке. B>Новая задача требует собирать некоторые данные пользователей и хранить их другим объектом. Вроде как обычное Key-Value выходит. B>Сервис публичный. Есть риск что данных станет очень много. Поэтому пихать много всего в MySQL не охота. B>Транзакции особо не нужны. Нужно хранить достаточно жирные объекты до 10Мб, а в будущем может и больше.
MongoDB + GridFS
B>Для каких задач можно получить преимущества от Graph или Column oriented хранилищ?
Аналитика
B>Правильно ли я понимаю, что такие решения как HBase являются полностью in-memory решениями? То есть, их вообще нет смысла использовать при отсутствии кластера в десяток серверов?
Все NoSQL решения нет смысла использовать на одной машине
Здравствуйте, Дельгядо Филипп, Вы писали:
ДФ>А какие RDBMS использовали?
Oracle, MySQL, SQL Server, Firebird. Сейчас есть тенденция к PostgreSQL для новых проектов.
ДФ>Сколько данных планируется (1e6, 1e9, 1e12)?
В штуках?
ДФ>Какой общий объем будет — гигабайты, терабайты?
Грубая и немного оптимистичная оценка говорит, что терабайты.
ДФ>Какие требования к запросам — только по ключу или сложнее?
Пользовательские по ключу. Возможно, будет некоторая внутренняя статистика, которая потребует сканировать все объекты с некоторой периодичностью, чтобы собрать данные. Но если она займет день, то это вполне приемлемо.
ДФ>Какие требования к скорости чтения/записи?
Строгих нет.
ДФ>Какие требования к надежности (можно потерять хоть все, можно потерять операции за несколько секунд и т п.)
Немного строже чем "можно потерять хоть все". Сервис включает платную подписку, такие данные терять можно, но в разумных пределах.
ДФ>Какие требования к HA — какой простой допустим для технических операций, какой в случае проблем с железом?
День, полагаю, допустим.
ДФ>Ну вот от этого и нужно отталкиваться )
Ты меня ещё больше запутал.
B>>Новая задача требует собирать некоторые данные пользователей и хранить их другим объектом. Вроде как обычное Key-Value выходит. ДФ>Обычное key-value — это монга. Вроде бы последний год уже не теряет данные просто так. Или postgresql с колонками типа json (надёжнее, быстрее, сложнее настраивать).
MongoDB смущает своим JSON-ом. Если у меня сериализованный бинарник 10Мб, то в JSON он станет только больше.
On 11.05.2016 11:33, Blazkowicz wrote:
> Начальник хочет поэкспериментировать с NoSQL на одном из проектов. Не > столько для пользы проекта, а чтобы получить опыт для будущих решений, > так как с RDBMS уже много чего накушались.
C NoSQL выбор блюд для кушанья не меньше )
> Обзорно читал про NoSQL, но никогда вплотную не использовал. Потратил > ещё пару дней на ознакомление, но каждый раз, когда начинаю читать про > конкретное решение, возникает ощущение что это не то что нужно. > Ткните, пальцем в алгоритм выбора.
Key-value store: Redis
Document-oriented: MongoDB
Column-oriented: Cassandra
> Проект уже в каком-то виде использует свой примитивный NoSQL. > Пользователи загружают свои данные в систему. Система строит отчет и > хранить его в виде сериализованного объекта в файле в облаке. > Новая задача требует собирать некоторые данные пользователей и хранить > их другим объектом. Вроде как обычное Key-Value выходит. > Сервис публичный. Есть риск что данных станет очень много. Поэтому > пихать много всего в MySQL не охота.
На последнем JPoint Сбертех много чего рассказывал про свой выбор, как я
понял из их слов — это допиливаемая под их нужды версия Apache Ignite.
Вот тут можно посмотреть подробнее: https://www.youtube.com/watch?v=3xJZ9_LOEhw
> Транзакции особо не нужны. Нужно хранить достаточно жирные объекты до > 10Мб, а в будущем может и больше.
Хранение массивных блобов — это не вполне конечно типичное применение
KV. А почему их просто в файлах не хранить в какой-нибудь GlusterFS?
> Для каких задач можно получить преимущества от Graph или Column oriented > хранилищ?
От Graph — для хранения всяких там графов связей и т.п. Где выгоды от
использования Column — я честно сказать сам так и не понял, может кто
прояснит. Знаю что его активно используют в "Одноклассниках" и они
реально контрибутят в неё.
> Правильно ли я понимаю, что такие решения как HBase являются полностью > in-memory решениями? То есть, их вообще нет смысла использовать при > отсутствии кластера в десяток серверов?
HBase — это, если я ничего не путаю, какая-то запчасть от хадупа,
который вообще вряд ли пригоден для вышеизложенной задачи.
Здравствуйте, hrensgory, Вы писали:
H>Хранение массивных блобов — это не вполне конечно типичное применение H>KV. А почему их просто в файлах не хранить в какой-нибудь GlusterFS?
Ну, я о том же. Сейчас примерно такая реализация и существует.
Смысл перехода на другое хранилище в том, что это не тупо блобы. Это вполне себе конкретные одинаковые структуры данных.
Иногда возникает желание что-то типовое из них всех вытащить и посчитать. Можно долго.
H>HBase — это, если я ничего не путаю, какая-то запчасть от хадупа, H>который вообще вряд ли пригоден для вышеизложенной задачи.
Мне просто шеф мозги проел BigTable. HBase — ближайший аналог. Но, судя по всему, вообще не под эту задачу.
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, Иль, Вы писали:
Иль>>Есть ощущение что вы "накушались" с MySQL, а не с RDBMS. Мы тоже накушались MySQL по самое не балуйся. Но переход на настоящую RDBMS и правильную работу с ней решает вопрос. B>А так же с Oracle, SQL Server и, особенно, Firebird.
Firebird — это, пожалуй, по личному опыту ещё печальнее чем MySQL. Вспоминается что там для изменения структуры данных надо переходить в однопользовательский режим. Хотя может быть уже и изменилось что-то...
Плохо, что в списке нет PostgreSQL. Он тоже не без внезапностей, конечно, но в последнее время стремительно развивается. В частности уже две версии работающее сочетание JSON + GIST вполне себе напоминает NoSQL.
On 11.05.2016 12:43, Blazkowicz wrote: > H>Хранение массивных блобов — это не вполне конечно типичное применение > H>KV. А почему их просто в файлах не хранить в какой-нибудь GlusterFS? > Ну, я о том же. Сейчас примерно такая реализация и существует. > Смысл перехода на другое хранилище в том, что это не тупо блобы. Это > вполне себе конкретные одинаковые структуры данных. > Иногда возникает желание что-то типовое из них всех вытащить и > посчитать. Можно долго.
