видимо настолько в точку, что какой-то неудачник, практикующий этот подход, ваш коммент минусанул :)
дешевые комплименты — да, это привнесенная с запада двуличность, типа «хаудуюду» в лицо с плевком на спину
из того, что вижу — кол-ва сообщений с разными статусами у юзера (10 прочитанных 5 непрочитанных) можно сделать аттрибутами юзера, сопровождая их на триггерах. Но перед тем, надо посмотреть на отношение (кол-во и тяжесть) между запросами «посчитай мне кол-во непрочитанных» и апдейтами «пометь как прочитанное»
Вопрос, что будет быстрее — каждый раз джойнить Message с Message_Status чтобы показать статусы сообщений, или все-таки продублировать статусы в обоих записях (что дает дополнительную гибкость) и поддерживать синхронизацию статусов двух связных сообщений например триггером.
> есть пруфлинк что в таком виде партиции улучшают производительность?
[showing off]Есть 10 летний опыт работы с реляционными СУБД поддерживающими не только партицирование, равно как и понимание этого механизма :)[/showing off]
Вот вы уповаете на индекс, но кроме операции чтения из индекса следующим шагом будет чтение набора записей из большой таблицы по физическим адресам строк, полученных из индекса. А где они расположены в этой таблице? Да где угодно, скорее всего равномерно по ней рассыпаны по мере исторического поступления в нее, т.е. фрагментированы. Приходится читать много блоков с диска с разных мест, даже если в каком-то блоке всего одна интересующая запись, этот блок читается целиком — дополнительные i/o. Какие преимущества тут дает партицирование? Записи в рамках одной партиции расположены _компактно_ физически друг к другу + в некоторых субд есть еще возможность задать им специфические параметры хранения — например раскидать по разным дискам.
> vsespb иначе бы можно было автоматически всем таблицам делать партиции и партиции партиций и всё было бы быстрее
Только не автоматически, но именно так и делают там, где оно применимо. Либо на этапе дизайна (с расчетом на будущую read capacity), либо, как сейчас, аврально, когда производительность уткнулась. Бывают ситуации, где и не применимо, тогда выбирают другие способы оптимизации — редизайн с денормализацией, введение материализованных представлений, функциональные индексы и т. п. не говоря о банальном изучении планов запросов и выбора лучших вариантов получения тех же самых данных
> столько же тиков (или больше) прибавляется учитывая что mysql выбрирает нужную партицию перед запросом.
Выбор партиции — копеечная операция — нет там никаких «столько же тиков (или больше)».
@ tyzhnenko — имхо вам надо перепланировать таблицу:
user_id — принадлежность сообщения пользователю
counterparty_user_id — вторая сторона переписки
message_direction (IN/OUT) — тип сообщения относительно владельца
Да, записей будет в два раза больше, но:
1) ведь так оно и должно быть, иначе в вашем текущем раскладе получается что если пользователь удаляет сообщение из аутбокса (решил почистить), оно пропадает из инбокса его визави :)
2) все сообщения одного пользователя будут локализованы в одной партиции
> тогда запросы будут равномерно распределены по всем партициям, это сводит выгоду от партиций на нет
Как раз наоборот. Физическая близость записей с одним id получателя в рамках одной партиции и даст прирост производительности. Партиции с точки зрения хранения суть разные таблицы — разделяя одну огромную таблицу партициями по хешу ключа наиболее частого поиска, вы по сути получаете N маленьких таблиц, над которыми ваши типичные поисковые выборки будут крутиться быстрее, в силу меньшего кол-ва записей в партиции и возможности сразу выбрать нужную партицию для поиска и ограничиться только ею (все сообщения одного пользователя локализованы в ней). Если раньше для поиска сообщений одного пользователя приходилось делать фулскан большого индекса (если он был) и access by row id к таблице либо фулскан всей таблицы (если не было индекса), то с учетом эквипартицированного индекса время скана уменьшится в N раз, где N кол-во партиций.
«на базе intel D510» еще надо купить и обеспечить его «в офисе или дома» резервным питанием, стабильным (+ резервным с автопереключением) каналом. Все это не стоит пары евров за вдс в забугориях.
Другое дело, если что-то в офисе уже выполняет роль сервера, и жутко хочется сэкономить, понимая и принимая все риски — тогда да, велком.
ptizza, оценки рисков субъективны, как и все в этом мире
вам кажется проект, в который инвестор вбухал деньги, высоко-рисковым, а ему наоборот видится депозит ситибанка со ставкой в 300%
В Москве когда переключались — прокатывало, народ покупал WiMax модемы с рук, оформлялся в йоте, подключал минимальный тариф и потом радостно получал новый модемы.
> рисовали в чем попало и как попало
А стандарты сверху спускаются? Или они декларируют только содержание, а не форму?
> Так что можно считать что все пользуются бумажками
Мое видение — нужно тупо внедрить/адаптировать какую-нибудь opensource систему учета/документооборота. Тыщи их. Тут больше аналитика и работы по внедрению, чем программирования. Боюсь только, без встречного движения сверху, инициатива загнется. Подобное решение надо продавливать не на уровне одного местячкового начальничка, которому и так неплохо в кресле, а на уровне отрасли.
Другой вариант — искать коммерческих пользователей для подобной системы.
> Ну как же не та аутитория?
Не, я не к тому. Тут вам по технической части помогут/подскажут/дадут направление. Основной же бой, как мне видится, будет не в области IT, а в области принятия решения.
kostin, да я с иронией. Все и так понятно.
Тоже офф-топик: пришлось как-то раз, краем уха заочно участвовать в сертификации — это был интересный экспириенс, критериев на самом деле много и проверяются они усердно. Но деньги в итоге вырулили над экспертизой.
Именно. Та же петрушка у мелких и средних телекомов. Они покупают коробочное сертифицированное биллинговое решение за пару сотен долларов, которое и демонстрируется в случае проверок, а клиентов считают своим биллингом — кривым, бажным и несертифицированным :)
«суммы не те, так что я бы не беспокоился» +1
Раз сюда подтягиваются люди знающие — кто-нибудь на вскидку может сказать что могут вменить в таком случае, если «услуги телематических служб» все-таки притянут за уши?
Не могу искоренить в себе национальную черту «А что за это бывает?» :-)
дешевые комплименты — да, это привнесенная с запада двуличность, типа «хаудуюду» в лицо с плевком на спину