Pull to refresh

Comments 15

а почему в PostgreSQL не реализуют —
create table t1 (as_of_date date) partition by range (as_of_date ) interval ( numtodsinterval(1, 'DAY') ) (partition p_min values less  than (date '1900-01-01'))?
Подход действительно интересный, вот только есть одно НО, и довольно большое — возможно я что-то пропустил, но я понял, что у вас один сервер БД и все. Предполагается, что допустим это логи по действию пользователя, робота, рекламы у вас на сайте. Все будет отлично пока у вас менее миллиона пользователей (это я с потолка для примера). Логи по ним будут собираться вы раз в день будете сбрасывать их в архив и т.д. Все довольны.

Но если пользователей становиться в 10 раз больше вы начинаете выбирать — или подрезать чаще, чем раз в день или хранить меньше статы. Так как ваш код не готов к работе с двумя подключениями. По хорошему надо сразу делать так, чтобы код не надо было переделывать из-за роста данных, так как рост данных (например набирающая оборот соц. сеть) вы не прекратите, сервер перполнится и вы будете говорить менеджеру проекта, что вам надо over 1 month на переделку кода. Прикол в том, что этого времени просто нет и вы можете потерять проект, так как пользователи просто уйдут от вас, так как не могут комментить, фотки заргружать и т.д.

Конечно, тут можно спорить о преждевременной оптимизации, улучшениях, которые возможно не понядобятся, если проект не выстрелит. Так вот — если он выстрелит и не справиться с возросшей нагрузкой, то он просто будет не нужен. А хороших проектов мало.
Полностью согласен. Этот подход, скорее для начальных и не слишком объемных проектов. После усиленного роста некоторые переползают на ту же MongoDB. Хотя это конечно зависит от поставленой задачи
обычно лучший вариант — это тот, кода код может быстро получить номер сервера, к которому надо обращаться за данными. при такой реализации, при условии кеширования карты например в redis оверхед будет минимальным.

Я не уверен, что монге можно и нужно говорить что и куда она кладет. Вот допустим у вас пользователи и их друзья, допустим у вас сайт vk.com с их посещаемостью. если у вас список друзей будет «размазан» по серверам средствами БД, то вы рискуете получить неопределенное кол-во запросов к шардовым серверам. Если же вы храните друзей одного пользователя на одном сервере, то запрос будет всего один. Еще лучше, если вы сумеете хранить инфу о пользователе и его друзей на одно сервере — тогда профит будет вообще крутой. Это я все про большие нагрузки.

К чему я это — о нагрузках надо думать в самом начале, иначе рискуете нарваться на переписывание кода — это не надо никому.
Разбиение графа на подграфы является NP-полной задачей.
Я видимо говорил не про то, что вы подумали, я про то, что если вы знаете номер пользователя, то несложно понять где он находится. Просто вы составляете карту типа такой: serverId spotId userIdFrom userIdTo. И очень быстро находите место нахождения пользователя.
наверно я неправильно понял, извиняюсь.
если стоит задача как-то хранить друзей, то наверно самый простой и быстрый вариант — хранить список друзей пользователя в поле(колонке) самого пользователя.
Самый быстрый хранить кеш в nosql, так как sql вечно что-то читает и пишет на диск при большом кол-во обращений. Даже тупо список друзей вывести будет проблема. Это лучше кешировать.
Postgres и сам справится с большими нагрузками, просто нужна правильная архитектура с горизонтальным масштабированием
Не соглашуть. Откуда pg знает на каком из серверов (!) хранятся данные об конкретном объекте? Сразу скажу, что рассматриваю ситуацию, когда на один сервер все данные не вмещаются (и это вполне реальная ситуация в большом проекте).

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

Слабое место постгреса — и оно было всегда — подобные вещи надо делать руками, и результат сильно зависит от квалификации. Этого быть не должно, СУБД потому и используют чтобы не писать свои велосипеды. Очень может оказаться, что дешевле для больших баз купить Oracle? получая поддержку, стандартизацию и готовых сертифицированных специалистов.
Оракл стоит денег, Постгрес нет. Сертифицированные специалисты стоят денег, постгрессовские тоже стоят но дешевле. Оракл стоит больших денег при масштабировании. Постгресс стоит только за разработку. Вообщем далеко не всем охото платить деньги за достаточно посредственную поддержку оракла.
При партицировании (разбиении?) таблиц в PostgreSQL нужно обращать внимание на довольно жесткое ограничение количества партиций (унаследованных таблиц? разделов?). На практике, количество таких партиций не должно быть более 50-100 (по рекомендациям вычитанным в Инете). Это связано с работой планировщика запросов, который перебирает все разделы, чтобы решить, к каким обращаться, и делает это линейно. И для 100+ партиций, по отзывам, он работает не эффективно, и тормозит запросы.

Также (хотя про это никто не пишет), меня одолевают сомнения, как файловая система будет работать с каталогом, содержащим файлы базы данных PostgreSQL (каждая база — один каталог, в котором каждый файл — это одна таблица или индекс), если мы создадим 1,000 партиций какой-нибудь таблицы скажем с 4мя индексами — 5 файлов на партицию = 5,000 файлов — это на одну такую супер-таблицу.

Я планировал сначала такое дело для нашей базы — разбить данные по месяцам и по клиентам, но количество разделов на 10 лет получается порядка 100,000-1,000,000 :-) так что я эту идею бросил, и начал думать в направлении раскладывать клиентов в разные схемы+тэйблспэйсы, а каждого из них в его тэйблспэйсе уже бить по годам — тогда количество разделов получается разумное.
ну практика показывает что 35 тысяч таблиц (без учета индекса) вполне работоспособно. Но конечно всякости вылазят просто со всех сторон и автовакумов нужно много и планировщик местами тупит, но все таки при нормальном объеме памяти и числе ядер вполне живуче.

Насчет приведенной схемы решения: 2 проблемы: constraint exclusion вещь линейная и при большом числе партиций ( уже на паре десятков заметно) реально планировщик начинает тупить. Спасет конечно Prepared Statement но оно не учитывает значения параметров при планировании и тут уже просто может пострадать эффективность запросов.

Вторая проблема это собственно производительность триггеров: вставка просядет.

А насчет партиционирования из коробки аля Оракл. Он деньгов собственно стоит. Так что в халявной СУБД уровня постгресса врядли будет. Я Вот МПП хочу. в оракле он как самолет стоит.
У меня сотни таблиц работают и ничего. Опять же вещь специфичная, и как подчеркивается в статье наиболее применима к данным, теряющим актуальность со временем. В свое время писал аналогичную статью
Sign up to leave a comment.