для традиционных RDBMS наверное реальный способ увелечение проиводительности это переход на быстрые системы хранения или городить типа ceph

на самом деле - без толку. реально RDBMS (транзакционная DBMS) таких нагрузок не тянет, и масштабирование у нее очень быстро заканчивается

... поправился прям на глазах, а давай в цифрах?

multimaster circular replication?

в mysql полномочия все

MySQL нормально с нагрузками справляется. Все нужно уметь готовить просто.

А что если я вам скажу, что вашу монгу, постгрес порвал где-то с год назад, при этом, с гарантированной записью, ага!

И да, с возможностью адресовываться в запросах

везде свои применения,просто когда у postgres упираешься в ресурсы сервера,есть смысл переходить на более мощный сервер(инфраструктуру), а не городить шардинг итд..

в банках это решают быстрыми системами хранения

MySQL нормально с нагрузками справляется. Все нужно уметь готовить просто.

мы говорим об 150 000 в секунду на запись

это уже не нормальная нагрузка

и да это дорого

в банках это решают быстрыми системами хранения

Но вернемся к вопросу, это медленно?

MySQL нормально с нагрузками справляется. Все нужно уметь готовить просто.

больше 100К/сек мне из него выжать не удалось никак. и никакая репликация на таких скоростях уже не работала.

нет это дорого

мы говорим об 150 000 в секунду на запись

Ну ка поясни?

это Daniel ставил такую задачу

пусть пояснит :)

А что если я вам скажу, что вашу монгу, постгрес порвал где-то с год назад, при этом, с гарантированной записью, ага!

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

... поправился прям на глазах, а давай в цифрах?

давай ты сам в цифрах, а?

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

Ну нам бы похер за аероспайк

Что за такие нагрузки 150 000 в секунду, аналитка событий от пользователя? Гугл и яндекс свои решения для таких кейсов пилят

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

аэроспайк не инмемори разве?

в памяти у него обязательно только индекс

аэроспайк не инмемори разве?

он может по-разному

Что за такие нагрузки 150 000 в секунду, аналитка событий от пользователя? Гугл и яндекс свои решения для таких кейсов пилят

не, просто вот такая была задача. http://incaller.org/

Какая задача?

мне там какой-то апп предлагают скачать...

))

апп из сторов смыло уже - проект-то 2016 года, и не взлетел

Ухх...бля, Даня, ну что это должно мне сказать?

примерно следующее: 10M пользователей (в реальности столько не было никогда, но тестировали с ориентацией на это число) создают примерно по 150 событий в сутки. при этом есть три горба, утром, в обед и вечером, когда - по расчетам - количество событий суммарное от них переваливает за 200К/сек

@onokonem прав

а шо там с амазоном в рамках контекста?

я не понял вопрос

ну RDS там, вся фигня..

я из не мерял

они же от нагрузки считают стоимость, и на таких нагрузках она выходит заоблачная

это факт

примерно следующее: 10M пользователей (в реальности столько не было никогда, но тестировали с ориентацией на это число) создают примерно по 150 событий в сутки. при этом есть три горба, утром, в обед и вечером, когда - по расчетам - количество событий суммарное от них переваливает за 200К/сек

на такой скорости можно уснуть

тем не менее - rdbms такую нагрузку уже не держит ни одна

ну пичалька, что сказать

в памяти у него обязательно только индекс

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

может была возможность синк реквестов батчами оформить

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

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

тем не менее - rdbms такую нагрузку уже не держит ни одна

Какую? У меня нет возможности платить за свои высказывания прямо, но я не беру свои слова назад - если я проотвечался - спрашивайте

а?!

..но ты на тот момент владел экспертизой, думаю предпринял возможные варианты по оптимизации

150K запросов на запись в секунду

ну хз что это за посты, может можно было объединять

150K запросов на запись в секунду

Даня,запись куда?

что - куда?

что - куда?

запросы покажи

150K запросов на запись в секунду

Зависит же от запросов и ещё кучи факторов

ну вот больше 100К из мускула (и больше 80К) из постгреса мне ни разу не удалось выжать

ну вот больше 100К из мускула (и больше 80К) из постгреса мне ни разу не удалось выжать

На сервер? Ну так поставь два

кстати, зря я это запросами называю. надо транзакциями называть.

И шардируй

шардинг приносит больше проблем, чем решает

Зависит же от запросов и ещё кучи факторов

Вопрос не к тебе, к хуесос

а?!

Вопрос не к тебе, к хуесос

А?

У тебя кажется т9

Специфический

наученый))

с кастомным словарем

Норм обучил т9

150к запись, а чтение?

ERROR: S client not available

чтение примерно такое же по количеству я тестировал

а движок какой? innodb?

хуесос))) аргумент дня!

тетировал кто Тарантул на не in memory движке?

а движок какой? innodb?

да. мне там транзакции были нужны, деньги с эккаунта списывать и количество показов инкрементить)

@onokonem в Яндекс.метрике долгое время бэкэнд был на мускулях

я в курсе

и даже знаю, как это сделать

но яндекс-метрика это довольно редкая задача, которая на шардирование ложится хорошо

на запись можно было попробовать RocksDB, там есть транзакции, и под MySQL есть в виде MyRocks.

ну может инкремент напрямую в базу не надо было писать in real time?

или пробовал?

ну если просмотр = списание денег, то какая разница как ты инкрементишь, если все в рамках транзакции)

но яндекс-метрика это довольно редкая задача, которая на шардирование ложится хорошо

Ну то что ты про вашу хреновину описывал тоже должно шардироваться хорошо

да. мне там транзакции были нужны, деньги с эккаунта списывать и количество показов инкрементить)

Стандартная практика делать это изредка по логам :)

а чо слабо транзакции на уровне прилодухи гошана делать? нах нужны субдшные транзакции? прошу высказаться!

Ну то что ты про вашу хреновину описывал тоже должно шардироваться хорошо

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

а чо слабо транзакции на уровне прилодухи гошана делать? нах нужны субдшные транзакции? прошу высказаться!

зачем, если хватает субд?

чтобы без транзакций юзать субд

там ещё на самом деле можно было глянуть SHOW PROFILES() ; и посмотреть на что тратится время.

..чем шардированный хуесос, я бы даже сказал..

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

Вопрос в том что вам нужно

Стандартная практика делать это изредка по логам :)

эт я не очень понимаю, как. там же надо с ssp расчитываться, перекручивать нельзя, а то из своих придется отстегивать

транзакции там ведь для прикрытия голожопой логики в аппликейшннах

эт я не очень понимаю, как. там же надо с ssp расчитываться, перекручивать нельзя, а то из своих придется отстегивать

речь про счетчик просмотров, видимо

или он на бабло завязан?

на бабло. это rtb dsp был

эт я не очень понимаю, как. там же надо с ssp расчитываться, перекручивать нельзя, а то из своих придется отстегивать

Стандартная практика в rtb всяком - выставлять счёт потом :)

Как раз потому что он может быть чуть больше бюджета

транзакции там ведь для прикрытия голожопой логики в аппликейшннах

показал баннер - увеличь счетчик и уменьши сумму на счете. хорошо бы без ошибок - там бабло

показал баннер - увеличь счетчик и уменьши сумму на счете. хорошо бы без ошибок - там бабло

Обычно бабло уменьшают таки асинхронно с небольшой задержкой

И счёт постфактум