Запись в БД об одной СМС не может весить 140 байт. Там помимо самого текста СМС (до 160 символов в 7-битной кодировке, до 70 — в 16-битной), MSISDN, всевозможных таймстампов будет хренова туча полей с информацией о тарификации на биллинге, возможно еще о маршрутизации.
Пытаюсь представить, сколько может весить база СМС-сообщений хотя бы одного из регионов одного из операторов большой тройки.
На самом деле, не так им и пофиг, они еще анализируют активность абонентов на предмет наличия фрода.
Не знаю, как это реализовано в Postgres, но в оракле я бы стал в данном случае использовать индекс по (billed, subscriber_id % 4), таким образом, чтобы range scan шел сначала по всем записям, у которых billed = 1, а затем уже делил на шарды по модулю.
Понял. В принципе, если у нас тысячи/миллионы абонентов и мы разделим их на 4 равных по количеству «лагеря», то и суммарный трафик у них будет примерно одинаков. Зато действительно удастся избежать лишних блокировок и потерянных обновлений.
Думаю, там имелось ввиду выражение call_id % 4, имеющее равномерное распределение.
Если брать subscriber_id % 4, то в каждом «шарде» будет разное число записей, зависящее от трафика конкретных абонентов.
Спасибо за топик. Сам работаю c хранилищами данных, так что интересно узнать, как там с OLTP-системами люди работают, для расширения кругозора, так сказать :)
Еще маленькое лирическое отступление, а то сферический конь получился хромым :)
Все-таки должно быть поле, например, billed (false или true), которое заполняется по-умолчанию false и переводится в true внутри функции.
Тогда функция должна работать только по тем записям, где billed = false. Ошибочка небольшая и вообще топик не о том, но она способствует некоторому непониманию.
Вот-вот. А даже если родителям несмотря на это будет как-то удаваться накормить ребенка, то вскоре он станет устраивать истерики и отказываться есть без лапочек.
Отлично!
Кстати, хороший подарок, ага. «Хочешь поссориться с подругой — подари ее ребенку барабан.» (с)
Параллелизм вообще штука противоречивая. Как хорошо заметил Кайт, распараллеливание — это способ максимизировать использование ресурсов системы. Получается, что оно нужно далеко не везде, а может, и наоборот навредить. Хотя для административных задач оно подходит хорошо.
Возвращаясь к теме, мне кажется, что если в штатном порядке работы приложения возникает необходимость производить параллельные запросы к секциям таблиц, то, возможно, что-то не так в архитектуре БД, или же таблица секционирована как-то неоптимально. Мало приходит в голову случаев, когда это было бы необходимо.
В принципе какой-то новой информации тут практически нет, т.к. интервью обзорное и рассчитано на людей, вообще не знакомых с яндексом и российским интернетом.
Но есть один момент, который хотелось бы отметить: «Сейчас проще найти деньги, чем мозги. так что если у вас есть идея, вы можете легко привлечь для нее инвестиции».
Это за 25x Named User Plus (NUP) Enterprise Edition 1 year + 25x NUP Partitioning без поддержки?
Хотя, я, конечно, понимаю, что это бредовый вариант, и нечто нормальное действительно может начинаться с 20К.
Отдельным сегментом, но не таблицей. Все-таки, нельзя сделать alter секции и изменить список столбцов в ней, например. Или навесить ограничение целостности только на одну секцию.
Ага, только не ставить, а покупать. Я так прикинул на shop.oracle.com, при самом дешевом раскладе (25 лицензий Named User Plus на 1 год и без поддержки) выходит 5900 долларов США (я не уверен, включены ли налоги). При этом надо понимать, что нет особого смысла покупать лиценизии на 1 год.
А тут дешево и сердито. А, может, и не так уж сердито, почитаем продолжение.
Получается, что именно секционирование как таковое в PostgreSQL отсутствует, но есть функционал для того, чтобы эмулировать его работу?
А можно, например, «вывести из строя» одну из секций таблицы, не повредив работе запросов над остальными секциями (как в оракле ALTER TABLESPACE… OFFLINE)?
Вы говорите, что люди создают организации для того, чтобы срубить бабла. Таки да, это действительно так! Но это цель учредителей/владельцев/акционеров, а не самой организации. В то время как сама организация удовлетворяет потребности рынка, а не ее владельцы.
Да, и я в курсе, что все должны получать прибыль, и желательно побольше — без нее далеко не уедешь.
Вообще это выросло в большой злостный оффтопик, предлагаю всем остаться при своем и баста.
На самом деле, не так им и пофиг, они еще анализируют активность абонентов на предмет наличия фрода.
в таком случае использование индекса будет оправдано
Если брать subscriber_id % 4, то в каждом «шарде» будет разное число записей, зависящее от трафика конкретных абонентов.
Еще маленькое лирическое отступление, а то сферический конь получился хромым :)
Все-таки должно быть поле, например, billed (false или true), которое заполняется по-умолчанию false и переводится в true внутри функции.
Тогда функция должна работать только по тем записям, где billed = false. Ошибочка небольшая и вообще топик не о том, но она способствует некоторому непониманию.
Отлично!
Кстати, хороший подарок, ага. «Хочешь поссориться с подругой — подари ее ребенку барабан.» (с)
Возвращаясь к теме, мне кажется, что если в штатном порядке работы приложения возникает необходимость производить параллельные запросы к секциям таблиц, то, возможно, что-то не так в архитектуре БД, или же таблица секционирована как-то неоптимально. Мало приходит в голову случаев, когда это было бы необходимо.
Но есть один момент, который хотелось бы отметить: «Сейчас проще найти деньги, чем мозги. так что если у вас есть идея, вы можете легко привлечь для нее инвестиции».
Хотя, я, конечно, понимаю, что это бредовый вариант, и нечто нормальное действительно может начинаться с 20К.
А тут дешево и сердито. А, может, и не так уж сердито, почитаем продолжение.
А можно, например, «вывести из строя» одну из секций таблицы, не повредив работе запросов над остальными секциями (как в оракле ALTER TABLESPACE… OFFLINE)?
Да, и я в курсе, что все должны получать прибыль, и желательно побольше — без нее далеко не уедешь.
Вообще это выросло в большой злостный оффтопик, предлагаю всем остаться при своем и баста.