алгоритмы определения ноды в шардинге

[MiksIr]

Ну redis cluster тоже вариант, да. У них у всех по сути один алгоритм - хеш ключа, определение "слота" (vbucket) - мапинг слота на ноду. Ну и + миграции слотов.
Другое дело, что если у тебя просто поток, который нужно куда-то хранить, что бы потом обрабатывать - такой алгорим вообще не очень подходит.

 

[fixxxer]

А что потом требуется с этими данными делать? Какие варианты поиска или обработки?
Если ничего особенного, можно класть в какой-нибудь distributed object store аля S3, типа ceph object storage.

 

[grigori]

А что потом требуется с этими данными делать? Какие варианты поиска или обработки?
Если ничего особенного, можно класть в какой-нибудь distributed object store аля S3, типа ceph object storage.

да, дальше обсчет и удаление
отдать заботу о шардинге на сторону стореджа - вариант, да, особенно при проектировании новой системы
у меня с ним возникает проблема увеличения зоопарка на еще один немаленький и мало кому известный сервис, когда уже есть редисы и swift, ты понимаешь что на это скажут одмины devops-ы
иногда проще реализовать сложную логику в приложении, чем изучать и сопровождать сторонний сервис

за вариант спасибо, не знал о нем

 

[fixxxer]

я б не сказал что ceph малоизвестный
https://www.google.com/trends/explore#q=/m/02643rf, /m/0cm87w_&cmpt=q&tz=Etc/GMT-3

 

[MiksIr]

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

 

[grigori]

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

 

[MiksIr]

нужна система обеспечния уникальности идентификатора куска данных - id фронта + id процесса + счетчик
распределенная файловая система - штука очень ненадежная - это как-то абстрактно, тем более я бы не использовал именно готовую распределенную систему. Решение в лоб - поднятие новой ноды, поток данных на ноду через какой-то интерфейс (банально ssh может быть) с контролем заполнения.
с локальными дисками нужна целая система сбора, группировки, объединения - mapreduce?
и уборки мусора - ноду убили - вот и мусор убрали
А так... я то не знаю, какие у тебя задачи, я напридумовал одну задачу, у тебя другая.

 

[grigori]

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

 

[MiksIr]

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

 

[fixxxer]

@grigori, ну не знаю, придумай такую, чтобы технически похоже, но с точки зрения бизнеса совсем другое, для примера. А то мы все по-разному тут требования понимаем. Не понятно, например:
- достаточно ли валить все связанное с одним id на одну ноду (или пару связанных нод), или надо мапить и редюсить во все поля?
- требуется ли работать одновременно с несколькими шардами?
- какое соотношение r/w?
- насколько для разных id (по которых шардишь) отличаются объемы данных?
- насколько часто появляются и удаляются новые id? надо ли в связи с удалениями решать проблему фрагментации?
- какого типа выборки нужны - по pk, по range? группировки, сортировки, джойны? в рамках одной шарды или нет?

 

[grigori]

Вот одна из конкретных задач. Аплоад видео медведей с мобильных телефонов из тайги по gprs с описанием и всякими важными данными. Потом это все надо связать, собрать, обработать и выложить вместе на bearpornhub.
Без дополнительных данных видео никому не нужно потому что без доказательства научных целей съемки можно нарушить конвенцию о жестоком обращении с животными.

За один запрос 100-мегабайтный файл не пролезет, его надо слать с клиента чанками - это js умеет. Теперь надо научиться собирать видео на сервере и переживать разрывы без приступов паники.
А медведей, конечно, много, и видео с ними пишут постоянно целыми днями. Не как людей на pornhub, но много, и не только бурых под Читой, но и панд в Тайланде. Вот железо не экономим совсем.

 

[MiksIr]

Я бы шел путем единой точки - менеджера страдж-нод (для получения списка доступных), и заложенного в id видо номера сторадж-ноды, что бы не нагружать центральную точку еще и этим мапингом.
Если центральной точки не хватает по производительности - она легко делится на несколько никак не связанных между собой, просто у каждой свой пул сторадж-нод.

Про тот же ceph - я не знаю, можно ли как-то настроить линейное заполнение нод, что бы писать файлы туда. Я его использовал только с фиксированным числом нод и добавление новой - это была разовая ситуация. А использовать его, что бы докупать диск в пиках - не приходилось.

 

[fixxxer]

Ага, я бы для такого ceph попробовал прежде чем велосипедить, кажется, должно подойти.

С cephfs только не связывайся, эмуляция семантики posix fs по сети - неблагодарное занятие. Это только если иначе никак.

 

[grigori]

покопаюсь в нем, спасибо

есть еще проблема с принципом глобального импортозамещения - правило "not invented here" блюдется строже ограничений на продажу алкоголя несовершеннолетним беременным неграм

 

[fixxxer]

Хаха. Яндекс вон свой ceph сделал, с кокаином и шлюхами.

Оно хорошее, но документировано в основном на языке C++.