ну поболтать там можно

Кто-нибудь ставил такие эксперементы? https://stackoverflow.com/questions/778534/mysql-on-duplicate-key-last-insert-id

Нужно, чтобы вставка в таблицу с unique индексами не выдавала ошибки, и в добавок возвращала уже ранее существующий ИД.

на Postgre както так insert into tbl (col1, col2, col3, ...) select nextval('tlb_id_seq'), t.col1, t.col2, ... from (values()) t (col1, col2....) where not exists ( select 1 from tbl where tbl.col1 = t.col1 and tbl.col2 = t.col2 ... ) returning id

Кто-нибудь ставил такие эксперементы? https://stackoverflow.com/questions/778534/mysql-on-duplicate-key-last-insert-id

Не понял, а зачем вообще трогать поле под индексом и юником? Оно же через СуБД заполняется автоматически именно последним+1 значением

Не понял, а зачем вообще трогать поле под индексом и юником? Оно же через СуБД заполняется автоматически именно последним+1 значением

Это была мысль в ночи, как использовать уники и не сломать мастер-мастер, но уже понял, что это не вариант.

Проще ходить скриптом и склеивать нужное.

Ясна

да выкиньтевы вообще идею об автоинкрементах

тот, кто их придумал, был пьян

да выкиньтевы вообще идею об автоинкрементах

Все вокруг идиоты, один ты Эйнштейн

д'артаньян все же

ничего не понял. есть же классика, 1) uuid 2) автоинкремент с шагом N. где N - максимальное число мастеров. И есть одна мысль - если у вас настоящий мастер-мастер, то, скорее всего, у вас нет бойцов, способных его нормально готовить.

ничего не понял. есть же классика, 1) uuid 2) автоинкремент с шагом N. где N - максимальное число мастеров. И есть одна мысль - если у вас настоящий мастер-мастер, то, скорее всего, у вас нет бойцов, способных его нормально готовить.

Ещё нету, тренируемся)

Вариант второй будет

Это очень дорого, в разработке и в поддержке. Я бы предпочел независимые БД с очередями сообщений. Ну да ладно

Читал тут на днях внутреннюю статью, где хвалились tps-ами на мастер-мастер, не прошло и недели, как он у них сломался.

Читал тут на днях внутреннюю статью, где хвалились tps-ами на мастер-мастер, не прошло и недели, как он у них сломался.

Что такое тпс и что конкретно там сломалось?

transactions per second. а пруф не помешал бы )

Что такое тпс и что конкретно там сломалось?

эм, а что обычно ломается на мастер-мастер? всё то же самое, даннае разъехались)

один мастер отстал а другой нет. а потом каак записали не того в отставший

Читал тут на днях внутреннюю статью, где хвалились tps-ами на мастер-мастер, не прошло и недели, как он у них сломался.

Мастер - мастер не увеличивает тпс, в чём хвастоство?

эм, а что обычно ломается на мастер-мастер? всё то же самое, даннае разъехались)

В асинхронной реплике никто и не обещал идентичности, с чего траблы?

один мастер отстал а другой нет. а потом каак записали не того в отставший

Это логика приложения траблит

Мастер - мастер не увеличивает тпс, в чём хвастоство?

то есть как не увеличивает?

Никак же, это ж не шарды

ничего не понял. есть же классика, 1) uuid 2) автоинкремент с шагом N. где N - максимальное число мастеров. И есть одна мысль - если у вас настоящий мастер-мастер, то, скорее всего, у вас нет бойцов, способных его нормально готовить.

А такие бойцы вообще есть?

Никак же, это ж не шарды

каждый мастер же принимает (че хочет) в том размере, в котором сможет, не консультируясь с остальными, разве нет?

ага а потом еще принимает то же самое от других мастеров

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

А такие бойцы вообще есть?

очень дорого, есть. все первым делом попросят уйти от этой техники.

а

Бггг, боец, который говорит, что в бой идти не надо? :)

обход - хорошая тактика, во многих случаях

каждый мастер же принимает (че хочет) в том размере, в котором сможет, не консультируясь с остальными, разве нет?

Если ты можешь в сервер А лить 2000 тпс максимум, то поставив второй такой же с М-М А-А рядом у тебя не будет 4000 тпс, у тебя будут раскиданны по 1000 тпс на каждую ноду.

Ты путаешь данный вариант с RAID0 / RAID10 массивами.

Единственное, что я встречал на работе и с СуБД MySQL, так это вариант, когда слэйв делается либо для чтений, либо для бэкапов, что бы не тормозил мастер на момент снятия дампа. Всё остальное видимо никто не умеет готовить нормально. Потому получили признание всякие NoSQL и шардообразные вариации.

Единственное, что я встречал на работе и с СуБД MySQL, так это вариант, когда слэйв делается либо для чтений, либо для бэкапов, что бы не тормозил мастер на момент снятия дампа. Всё остальное видимо никто не умеет готовить нормально. Потому получили признание всякие NoSQL и шардообразные вариации.

Значит вы очень редко встречались с ними. Слэйв для чтения это уже стандарт на полтора десятка лет.

Так у nosql принцип такой же, просто изза внутренней простоты они шардируются из коробки

Что тоже не всегда хорошо

Монгос умеет занять весь кластер решардингом вместо работы

Хорошо мне с моими smalldata проектами, которые в sqlite прекрасно живут =)

Ну эскулайт может много в себя вместить. У него с конкаренси не очень

Так у nosql принцип такой же, просто изза внутренней простоты они шардируются из коробки

Хорошо. 1. NoSQL умеет геораспределённое шардирование? 2. Я могу ему задавать сложные запросы выборки данных для подбора идеального рекламодателя на лету?

Монгос умеет занять весь кластер решардингом вместо работы

Кластер это насколько я понимаю несколько машин с одной системой хранилища, как у Оракла, либо много хранилищ, много машин, но репликация синхронная, как у галлеры.

Хорошо. 1. NoSQL умеет геораспределённое шардирование? 2. Я могу ему задавать сложные запросы выборки данных для подбора идеального рекламодателя на лету?

Для начала надо определить что такое nosql. Посгре вон тоже nosql - "not only sql" ©

Кластер это насколько я понимаю несколько машин с одной системой хранилища, как у Оракла, либо много хранилищ, много машин, но репликация синхронная, как у галлеры.

В монге нет синхронного

Хорошо. 1. NoSQL умеет геораспределённое шардирование? 2. Я могу ему задавать сложные запросы выборки данных для подбора идеального рекламодателя на лету?

1 любое что ты напишешь в коде:) 2 можешь чо нет, просто это будет "не так как sql"

Моя задача: Приходит пользователь А из Бонуэс-Айреса, ему надо отдать контент с минимальной задержкой, секунда не более. А спустя "очень короткий промежуток времени" приходит пользователь Б из Сиднея, и ему я тоже должен отдать контент. И допустим им нужен один и тот же контент, только вот проблема в том, что после посещения юзера А квота рекламодателя на контент исчерпана. Об этом должна вся система знать в идеале не более чем через 5 секунд, после того, как этот пользователь А зашёл.

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

А "знать вся система" не требкет синхронности же

И того задача и тому и другому отдать нужный контент очень быстро, но чтобы друг о други "знали"

Так вот в моём видение оптимального расклада "очень короткий промежуток времени" это не более секунды, а "знали" не более 5 секунд.

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

Так и делается. у ТДС один домен, ДНС система от амазона сама занимается распределением трафика на конечные точки входа.

Там стоят сервера со скриптами.

Таких точек будет 10-12

Балансировка на базе днс?

Route53 от амазона

Это не столько балансировка

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

Хорошо. 1. NoSQL умеет геораспределённое шардирование? 2. Я могу ему задавать сложные запросы выборки данных для подбора идеального рекламодателя на лету?

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

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

Читай дальше, я расписал. Как дочитаешь до этого поста, если что-то не внятно пояснил, спроси уточнения, я отвечу.

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

Гм... если оно через edns работает, то это не совсем честно, тк далеко не все серверы его умеют

ну да, тебе нужна не централизованная система, а несколько датацентров, каждый из которых едва знает о существовании остальных

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

ERROR: S client not available

Гм... если оно через edns работает, то это не совсем честно, тк далеко не все серверы его умеют

Поясни, я не совсем понял суть написаного (

Моя задача: Приходит пользователь А из Бонуэс-Айреса, ему надо отдать контент с минимальной задержкой, секунда не более. А спустя "очень короткий промежуток времени" приходит пользователь Б из Сиднея, и ему я тоже должен отдать контент. И допустим им нужен один и тот же контент, только вот проблема в том, что после посещения юзера А квота рекламодателя на контент исчерпана. Об этом должна вся система знать в идеале не более чем через 5 секунд, после того, как этот пользователь А зашёл.

да твои условия по-моему вполне укладываются в существующие возможности интернета

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

сла?

service layer agreement, те ограничения по вермени, которые ты описал

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

Поясни, я не совсем понял суть написаного (

Есть edns-client-subnet, который передаётся в запросе от рекурсивного сервера, чтобы авторитативный сервер знал откуда клиент и выдал ему максимально близкий ip-шник

если рекламодатель исчерпает бюджет на +5 баксов - это будет проблема дешевле, чем поддержвать все это в живом состоянии

Ну 5 секунд это 95% идеал

На пиках будет простреливать, и пускай, терпимо

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

Это ж не обязательное условие что бы уложиться в секунду. Текущие задержки от России до Америки не более 300мс

И этот самый edns-client-subnet поддерживают далеко не все рекурсоры и авторитативный сервер будем ориентироваться не по тому где находится клиент а по тому, где находится его рекурсивный сервер

Ну и плюс промежуточные кеши

Получается, что даже если 300 до другого конца планеты, плюс 300 обратно, остаётся ещё 400мс на выдачу результата

Это ж не обязательное условие что бы уложиться в секунду. Текущие задержки от России до Америки не более 300мс

Вооооооооооот. Уже не плохо. НО. Это только пинг. А ещё вычисления, ещё несколько операций с базой. И того набегает. Я начал с Ирландии, потом поставил слейв в Калифорнии, потом сказали Азию добавить, поставил в Сингапуре, ну по моей логике главное было скриптосервер поближе к юзеру подтянуть, и дать ему реплику. А тот факт, что там идут записи, я прошляпил. И пишут мне манагеры "Чё за фигня, у нас потери трафика, ТДСка долго грузится!" я проверяю, а там 6 секунд на вшивый редирект. ШЕСТЬ СЕКУНД. Начал копать. Ну да, клиент до скриптосервера долетает за 50мс, а скриптосервер до мастера тратит по полторы секунды на одну запись, а их часто до 3 штук поочерёдно. ТАДАМ.

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

Несколько миллиардов записей.

Запросы типа "покажи записи от 10.10.2010 до 10.10.2011 по МСК".

Благодарю, если кто-то что-то подскажет.

Так вот. Я поднял сервера на всех локациях доступных в амазоне. Устроил получасовой пинг всех на всех. И нарисовал карту скоростей между точками. Выделил 3 группы: Америка, Европа, Азия. В каждой по сумме пингов выявил сервер, который наиболее идеально минимальный пинг до всех других в своей группе имеет. И это будут у меня 3 мастера. Итого схема будет такая. юзер А (из задачи сверху) будет направлен на сервер в Сау-Паулу, все нужные селекты он запросит с слейв-реплики находящейся там же, а когда ему нужно сделать запись, он её сделает на Мастер сервере в Ohio, на это уйдёт меньше секунды, потом эта инфа через ещё секунды-полторы окажется в Сингапуре, где стоит второй Мастер, и ещё через столько же в Сиднее, где стоит слейв реплика от Сингапурского мастера.

Запросы типа "покажи записи от 10.10.2010 до 10.10.2011 по МСК".

Меня закидают тапками, но я бы сначала сдвигал до UTC, переводил бы в unixtimestamp а потом искал по колонке int(10) unsigned которая была бы индексом.

А в выдаче всех бы вновь свдигал обратно построчно до нужного отступа по таймзоне

Вооооооооооот. Уже не плохо. НО. Это только пинг. А ещё вычисления, ещё несколько операций с базой. И того набегает. Я начал с Ирландии, потом поставил слейв в Калифорнии, потом сказали Азию добавить, поставил в Сингапуре, ну по моей логике главное было скриптосервер поближе к юзеру подтянуть, и дать ему реплику. А тот факт, что там идут записи, я прошляпил. И пишут мне манагеры "Чё за фигня, у нас потери трафика, ТДСка долго грузится!" я проверяю, а там 6 секунд на вшивый редирект. ШЕСТЬ СЕКУНД. Начал копать. Ну да, клиент до скриптосервера долетает за 50мс, а скриптосервер до мастера тратит по полторы секунды на одну запись, а их часто до 3 штук поочерёдно. ТАДАМ.

Да, я понял о чём речь. Тут и правда нужно что-то похожее на мульти-мастер...

А в выдаче всех бы вновь свдигал обратно построчно до нужного отступа по таймзоне

Делаем это прямо сейчас.

Вот я подумал, может быть есть какое-то специализированное решение для таких запросов.

И как скорость по нескольким миллиардам?

Ну смотря какие запросы...

Некоторые отрабатывают в фоне раз в X минут/часов.

Арендуете сервак или прямой доступ к железу?

Некоторые в живом режиме.

Арендуете сервак или прямой доступ к железу?

Да пока арендуем.

Просто если бы была своя железка в НИИ (ну как пример), можно было бы её затюнить под эту задачу, если она у вас настолько генерально важная.