Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Нужна платная консультация по горизонтальному шардингу и настройка / 8 сообщений из 8, страница 1 из 1
23.03.2016, 14:39
    #39198817
nateless
nateless
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Нужна платная консультация по горизонтальному шардингу и настройка
В общем я понял что трачу слишком много времени на эту проблему и пришло время обратиться к специалисту.

Нам нужен горизонтальный шардинг на 2-3 сервера с единой точкой входа для Rails приложения которое вообще ничего не должно знать про шардинг. C поддержкой ACID. Дальнейшая оптимизация БД. Для нас не критична HA, даже в случае полной потери всех данных мы можем все восстановить запустив начальные алгоритмы. Важна максимальная скорость, это несколько тысяч операций INSERT\SELECT\UPDATE в секунду.

Пишите пожалуйста на natetuganov at gmail com. Интересуют только люди с РЕАЛЬНЫМ опытом и high load, желательно с отзывами.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
24.03.2016, 02:24
    #39199204
Maxim Boguk
Maxim Boguk
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Нужна платная консультация по горизонтальному шардингу и настройка
natelessВ общем я понял что трачу слишком много времени на эту проблему и пришло время обратиться к специалисту.

Нам нужен горизонтальный шардинг на 2-3 сервера с единой точкой входа для Rails приложения которое вообще ничего не должно знать про шардинг. C поддержкой ACID. Дальнейшая оптимизация БД. Для нас не критична HA, даже в случае полной потери всех данных мы можем все восстановить запустив начальные алгоритмы. Важна максимальная скорость, это несколько тысяч операций INSERT\SELECT\UPDATE в секунду.

Пишите пожалуйста на natetuganov at gmail com. Интересуют только люди с РЕАЛЬНЫМ опытом и high load, желательно с отзывами.

Hm, что то у меня не совмещается в голове "шардинг на 2-3 сервера" и "несколько тысяч операций INSERT\SELECT\UPDATE в секунду". Или вам шардинг не нужен или требуемые TPS на 2-3 порядка выше. Несколько тысяч делаются на 1 несильно дорогом сервере без особых плясок с бубном (хотя конечно смотря какие SELECT да, могут быть такие что ничего не поможет сделать 1000TPS).
Честный ACID в шардинге возможен только для postgresql-XL и если вы не крупный телеком или банк с соответствующим бюджетом - он вам не нужен (да и эксплутировать его еще та задача). Аналогично - с полной прозрачностью для приложения.
Я бы посоветовал бы взять 1 нормальный сервер + реплику и нормально настроить а дальше уже думать.

--
Maxim Boguk
www.postgresql-consulting.ru
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
24.03.2016, 10:39
    #39199348
qwwq
qwwq
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Нужна платная консультация по горизонтальному шардингу и настройка
Maxim Boguk,

у т--рища не типовое oltp, а скорее вычислительная матричка со сложным состоянием, которое перевычисляется эти самые "несколько тысяч раз в секунду", причем в индексах типично лежит по 10--15 кило мертвых версий [листьев], при отсутствии живого:
http://www.sql.ru/forum/1202248/ochen-dolgiy-update-na-30m-zapisey?mid=18859272#18859272

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

скорее всего ему нужна какая-нть in--memory шняжка, очень может быть -- блокировочная [без 1000 версий в мусоре], а вовсе не пж -- для хранения промежуточных состояний его матрички.
ну или переписать и перепродумать всю схему вычислений и хранения "состояний".

если б не проблемы с паршионингом при >>1000-х узлов -- я бы подумал в пж про ротируемые короткоживущие махонькие партиечки , с транкейтами отротированных саб--партиечек, вместо вакуумов и реиндексов. "а так -- нет"(сс)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
24.03.2016, 12:14
    #39199499
mad_nazgul
mad_nazgul
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Нужна платная консультация по горизонтальному шардингу и настройка
Как это

nateless C поддержкой ACID.

Коррелирует с этим

nateless Для нас не критична HA, даже в случае полной потери всех данных мы можем все восстановить запустив начальные алгоритмы. Важна максимальная скорость, это несколько тысяч операций INSERT\SELECT\UPDATE в секунду.


Т.о. СУРБД для вас не нужна, более того вредна!

Скорее всего будет достаточно файла или любой NoSQL - системы.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
24.03.2016, 13:12
    #39199606
qwwq
qwwq
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Нужна платная консультация по горизонтальному шардингу и настройка
mad_nazgul,

очевидно acid нужен чтобы в 100 смычков хором теребонькать свою матричку, не задумываясь о реализации собственных механизмов поддержания консистентности в "файлике", при работе в 100500 потоков.

т.к. в РСУБД "всё включено", типа.

спорно, но понятно.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
24.03.2016, 15:01
    #39199815
nateless
nateless
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Нужна платная консультация по горизонтальному шардингу и настройка
Maxim Boguk,

Если я правильно понял PG, то реплика тянет данные с мастера. В нашем случае при такой скорости записи чтения возможно ситуация когда данные не дойдут до реплики при запросе. Кроме того достаточно сложно разделить логику записи на мастер, чтение с реплики в Rails приложении.

qwwq,

Вы правы на счет ACID, но боюсь я не понял всего остального, в том числе отсылки на мой линкедин. Я сразу сказал что я не DBA и могу во многом ошибаться в силу своих поверхностных знаний. Имменно поэтому ищем консультацию.

mad_nazgul,

Нам нужна транзакционность.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
24.03.2016, 15:30
    #39199852
qwwq
qwwq
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Нужна платная консультация по горизонтальному шардингу и настройка
nateless,

т.е. поцгресс вам не принципиален.

попробуйте какой-нито блокировочник, типа DB2.
у него довольно либеральный экспресс--эдишн.
Или очередь на чтение вам тоже требуется исключить ?

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

шардинг вам не даст ничего, кроме дополнительных проблем (хотя бы в выборе доступных языков). а если, не дай бог, транзакции не усекаются до размера одной шарды, а потребуется распределённость -- вы наверняка проиграете в разы и в скорости
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
25.03.2016, 08:30
    #39200259
mad_nazgul
mad_nazgul
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Нужна платная консультация по горизонтальному шардингу и настройка
natelessMaxim Boguk,
Нам нужна транзакционность.

Вообще-то органиченный вид транзакционности есть в некоторых NoSQL.
Ну или можно каким-то образом эмулировать.
Т.к. вы сами сказали, что "потеря данных не критична", то ACID вам не нужен.
Возможно вам достаточно будет какого-либо вида "save point".

P.S. Прошу прощения за аналогию, но у меня складывается впечатление, что вы хотите сделать из грузового самосвала гоночный болид. :-)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Нужна платная консультация по горизонтальному шардингу и настройка / 8 сообщений из 8, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение  
Полит. конфиден.  
созд. / загр.: 401ms
Закрыть
start [/forum/topic.php?fid=53&mobile=1&tid=1997330]:
 0ms
get settings:
 10ms
get forum list:
 20ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 40ms
get topic data:
 12ms
get forum data:
 3ms
get page messages:
 48ms
get tp. blocked users:
 2ms
others: 258ms
total:  401ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]