Какую выбрать технологию для хранения и выборки больших данных?

Question

[Артем]

Всем привет!

Есть задачка следующего вида.
Есть много юзеров (десятки тысяч). Для каждого юзера необходимо хранить некие короткие текстовые данные. Для одного юзера может храниться 10 строк, для другого 10000, для третьего - миллион - для каждого юзера количество хранимых строк разное. Строки могут повторяться между юзерами.
Вопрос: какую из современных bigdata-технологий стоит выбрать для хранения этой информации, при условии, что:
1. Доступ будет осуществляться из c# - следовательно, нужен драйвер для c#
2. Поиск будет происходить по юзеру - то есть запрос вида "выбрать все строки, принадлежащие юзеру Х" будет наиболее частым запросом.
3. Поиск и выборка должны происходить максимально быстро (миллисекунды), независимо от количества юзеров и строк в базе.

Comments

[sim3x]

Какая сейчас технология используется?
Что гугл подсказал?

[Артем]

sim3x, Сейчас все в файлах хранится, что накладывает некоторые ограничения и неудобства.
Гугл подсказывает большое количество разных систем, но интересует именно опыт сограждан, а не десятки попыток применить ту или иную технологию, что равно потраченным впустую неделям.

[d'Ivan]

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

[Артем]

Роман Мирр, вопросы железа я бы пока оставил в стороне, нет проблем поставить какой-нибудь рейд на SSD для увеличения скорости выборки, равно как и организовать кластер из нескольких машин
вопрос именно в технологии, которая это потянет

[sim3x]

Артем, поисковиков, в открытом доступе два
sphinxsearch
elastic

[Артем]

sim3x, мне не нужен полнотекстовый поиск

[sim3x]

Артем, тогда берите постгрес, делайте 3NF, делайте несколько слейвов
Или мемкеш

В зависимости умении и требований к сохранности данных

[Артем]

sim3x, в мемкеш, боюсь, вся база не поместится - она сейчас около 100 гб и каждый день увеличивается на ~500 Мб
как насчет всяких хадупов и прочего похожего?

[sim3x]

Артем, 1Тб ram не было проблемой поставить на 1 машину 3 года назад

У вас требование - мс задержки
Учитывая, что у вас будет 10-500мс на сети, то ответ от СУБД требуется дать за <1мс

Укажите ваши приоритеты

[Артем]

sim3x, да, с памятью понятно, возможно это хороший вариант, буду думать в сторону in-memory databases, спасибо

[d'Ivan]

Артем, а в чем необходимость делать выборку всех миллионов записей за один запрос? Ведь миллион строк за 1 раз не просто ни отобразить ни на экране, ни передать по сети?! Это тупо много данных.

[stratosmi]

Артем,

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

Есть проблема.
У вас нет компетентных специалистов, которые это смогут сделать.
Вы даже не понимаете, что RAID на SSD не панацея.

[stratosmi]

равно как и организовать кластер из нескольких машин
вопрос именно в технологии, которая это потянет

Вы серьезно считаете, что ваши так называемые "специалисты", называющие словом BigData самую что ни на есть рядовую задачу, способны будут поднять кластер?

[stratosmi]

Вопрос: какую из современных bigdata-технологий

3. Поиск и выборка должны происходить максимально быстро (миллисекунды), независимо от количества юзеров и строк в базе.

Бигдата и "мгновенно" - это 2 взаимоисключающих понятия.

[stratosmi]

Поиск и выборка должны происходить максимально быстро (миллисекунды), независимо от количества юзеров и строк в базе.

Независимо от количества? Ха-ха.
А если у пользователя будет данных на 100 петабайтов?
Найти-то вы может и найдете, но как вы прочитаете с диска и отдадите в сеть 100 петабайтов за миллисекунду.

[Артем]

stratosmi, у нас вообще нет специалистов - всем занимаюсь я один. И фронтендом, и бекэндом, и администрированием на данный момент двух серверов. Разве что маркетингом не занимаюсь пока что ) Компетенции - дело наживное, научусь.

[stratosmi]

Артем,

в мемкеш, боюсь, вся база не поместится - она сейчас около 100 гб и каждый день увеличивается на ~500 Мб
как насчет всяких хадупов и прочего похожего?

Через 5 лет будет всего лишь 1 терабайт.

Вы что, серьезно, считаете эти детские объемы достойными Хадупа с его нормальной работой на петабайтах данных?

Самый банальный PostgreSQL способен на куда как большее

Limit Value
Maximum Database Size Unlimited
Maximum Table Size 32 TB
Maximum Row Size 1.6 TB
Maximum Field Size 1 GB
Maximum Rows per Table Unlimited
Maximum Columns per Table 250 - 1600 depending on column types
Maximum Indexes per Table Unlimited

Это не значит, что его рекомендую, - у вас невнятная постановка задачи, нельзя сказать определенно, что вам надо.

[Артем]

stratosmi, Я ничего не считаю, потому задал здесь этот вопрос.

[stratosmi]

Артем,

Я ничего не считаю, потому задал здесь этот вопрос.

Вы ничего не задали.
Вы придумали, что вам нужна BigData.
Если вы желаете получить внятную помощь - то внятно формулируйте задачу.

Answer 1

[FanatPHP]

Никакую. К big data указанные объемы отношения не имеют.
Подойдет любая СУБД, так что можно выибарть ту, которая больше знакома.

Тем более, что

Строки могут повторяться между юзерами.

Т.е. в нормализованном виде это будет занимать еще меньше места.

Лично мне куда интереснее другой вопрос. Что будет делать система с миллионом строк после запроса

"выбрать все строки, принадлежащие юзеру Х"

.

Comments

[Артем]

Что будет делать система с миллионом строк после запроса

Преобразовывать в 4 формата файла, архивировать в 1 архив и отдавать пользователю.

[FanatPHP]

Артем, тогда сразу архив и хранить.

[Артем]

FanatPHP, Сейчас так и происходит. Но есть неудобства в виде:
1. Если понадобится доступ ко всем строкам - придется разархивировать все архивы (а их уже около миллиона), затем делать поиск или другие операции с каждым из миллиона файлов. Куда проще сделать условный select disninct и получить сразу нужные результаты.
2. Нет резервирования "из коробки", которое есть в базах данных, когда настроил репликацию и получаешь копию базы на другом компе в режиме онлайн. Сейчас приходится для этого лить на FTP - жуткий костыль же.
3. Огромное количество файлов, даже при правильном подходе к организации иерархии, не лучшим образом сказывается на производительности жестких дисков и скорости доступа.

[FanatPHP]

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

Третий пункт я не понял. Вы всерьез считаете, что получить по сети некий объем данных, записать его в 4 файла, создать из них пятый и потом отдать пользователю - это даже в теории может быть быстрее, чем просто отдать существующий файл?

> Огромное количество файлов, даже при правильном подходе к организации иерархии, не лучшим образом сказывается на производительности

Обязательно расскажите об этом всем CDN провайдерам, а то они и не догадываются, что находятся на грани катастрофы.

[Артем]

Третий пункт я не понял. Вы всерьез считаете, что получить по сети некий объем данных, записать его в 4 файла, создать из них пятый и потом отдать пользователю - это даже в теории может быть быстрее, чем просто отдать существующий файл?

Конечно, это не будет быстрее.
Вопрос-то в другом.
Вопрос в том, как лично вы спроектируете подобный сервис - с использованием набора файлов или с использованием БД или другой технологии, специально предназначенной для хранения большого объема данных? С точки зрения надежности и удобства хранения и извлечения данных.

[FanatPHP]

Артем, я написал выше. Если "выбрать все строки, принадлежащие юзеру Х" это наиболее частый запрос, результат надо кэшировать.
Можно сделать порог, до 100 строк отдавать динамически, остальное кэшировать в файлы

[Артем]

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

[FanatPHP]

Артем, странно, что именно это я и написал 2 часа назад.

[Артем]

FanatPHP, Да, я видимо не воспринял информацию. Спасибо.

[stratosmi]

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

Обязательно расскажите об этом всем CDN провайдерам, а то они и не догадываются, что находятся на грани катастрофы.

У них выбора нет. Они услуги предоставляют. И не могут вместо миллиона файлов отдать один. Они могут отдавать только так, как пользователю/покупателю услуг надо.
Все правильно написано - получить один огромный файл быстрее, чем миллион мелких.

[АртемЪ]

Артем,

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

О каком объеме информации идет речь в сумме по всем клиентам - ориентировочно? Гигабайты, сотни гигабайт, террабайты.

[АртемЪ]

Артем,

Можно и в файлах хранить, и в базе. Пользователям быстро отдавать файлы, а в случае необходимости быстрого доступа ко всем строкам или какого-резкого падения - доставать из базы или её реплики.

Это называется кэширование :)

[Артем]

АртемЪ, ну типа да )

Answer 2

[hx510b]

10тыс пользователей * 1 млн строк по 200 байт = 2ТБ - максимальный размер базы - великовато для MySQL, но работать будет даже в лоб.
Раз строки повторяются, то нужно сделать словарь строк, и оперировать уже id строки.
Раз таблица пользователь-строки может оказаться очень длинной и ее изменение будет приносить большие задержки. То есть смысл резделить таблицу с информацией о строках пользователей на несколько таблиц (партиционирование), разделив весь пул пользователей по конкретным таблицам, чем больше таблиц - тем легче будет проходить обновления.
итого имеем такую структуру:

таблица users,
в которой id пользователя, некое внешнее описание пользователя, номер/имя таблицы с данными

таблица dict,
в которой храним уникальные строки и их id

пачка таблиц usersdata1...N,
в которых храним id пользователя и id строки, если у пользователя строки могут повторяться - то уникальный key id, чтобы хранить дубликаты строк и вытягивать их в порядке key id
чем больше N - тем веселее будут проходить изменения.

Выборка видится такой - ищем в users пользователя, берем его id и знание какую таблицу userdata надо опрашивать, затем выбрать из userdata список id строк, сразу подтягивая строки из dict.
Выбор таблицы можно делать, не храня данные о таблицах, например, по первым символам хеша "имени пользователя". Но такой принцип делает фиксированным количество таблиц userdata, это может оказаться не очень гибким способом для последующих изменений.

Потом такую базу можно перенести на raid из ssd, чтобы чтение происходило с минимальными задержками на чтение.
Если захочется еще повысить производительность, то userdataN можно размазать на разные хосты. При этом таблицы dict и users реплицировать между хостами средствами mysql.
Можно и миллионы пользователей так обслуживать, имя соответствующий парк серверов.

Comments

[stratosmi]

10тыс пользователей * 1 млн строк по 200 байт = 2ТБ - максимальный размер базы - великовато для MySQL, но работать будет даже в лоб.

Этого им хватит на 9 лет при теперешнем темпе роста данных

в мемкеш, боюсь, вся база не поместится - она сейчас около 100 гб и каждый день увеличивается на ~500 Мб
как насчет всяких хадупов и прочего похожего?

[hx510b]

stratosmi, Если индексы сделаны нормально в БД - mysql будет вытаскивать все бодро - memcached тут зачем?

[Артем]

hx510b, А индексы нормально - это как? B-Tree по user_id - это нормально или нет?

[stratosmi]

hx510b,

Если индексы сделаны нормально в БД - mysql будет вытаскивать все бодро - memcached тут зачем?

Мемкэш тут не при чем.
Приведена цитата автора темы, в которой упомянут размер данных. То, что в этом же предложении попался мемкэш - к делу не относится.

[stratosmi]

Артем,

А индексы нормально - это как? B-Tree по user_id - это нормально или нет?

1. Данные то только у тебя.
   
2. Нужно это тебе
   
3. Вот ты сам и попробуй и сравни на своих данных
   

[hx510b]

Артем, да будет работать. на 900 гб базе работало

[Артем]

stratosmi, Ну в принципе логично. Попробую.

[Артем]

hx510b, спасибо