Комментарии 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'))?
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'))?
+2
Подход действительно интересный, вот только есть одно НО, и довольно большое — возможно я что-то пропустил, но я понял, что у вас один сервер БД и все. Предполагается, что допустим это логи по действию пользователя, робота, рекламы у вас на сайте. Все будет отлично пока у вас менее миллиона пользователей (это я с потолка для примера). Логи по ним будут собираться вы раз в день будете сбрасывать их в архив и т.д. Все довольны.
Но если пользователей становиться в 10 раз больше вы начинаете выбирать — или подрезать чаще, чем раз в день или хранить меньше статы. Так как ваш код не готов к работе с двумя подключениями. По хорошему надо сразу делать так, чтобы код не надо было переделывать из-за роста данных, так как рост данных (например набирающая оборот соц. сеть) вы не прекратите, сервер перполнится и вы будете говорить менеджеру проекта, что вам надо over 1 month на переделку кода. Прикол в том, что этого времени просто нет и вы можете потерять проект, так как пользователи просто уйдут от вас, так как не могут комментить, фотки заргружать и т.д.
Конечно, тут можно спорить о преждевременной оптимизации, улучшениях, которые возможно не понядобятся, если проект не выстрелит. Так вот — если он выстрелит и не справиться с возросшей нагрузкой, то он просто будет не нужен. А хороших проектов мало.
Но если пользователей становиться в 10 раз больше вы начинаете выбирать — или подрезать чаще, чем раз в день или хранить меньше статы. Так как ваш код не готов к работе с двумя подключениями. По хорошему надо сразу делать так, чтобы код не надо было переделывать из-за роста данных, так как рост данных (например набирающая оборот соц. сеть) вы не прекратите, сервер перполнится и вы будете говорить менеджеру проекта, что вам надо over 1 month на переделку кода. Прикол в том, что этого времени просто нет и вы можете потерять проект, так как пользователи просто уйдут от вас, так как не могут комментить, фотки заргружать и т.д.
Конечно, тут можно спорить о преждевременной оптимизации, улучшениях, которые возможно не понядобятся, если проект не выстрелит. Так вот — если он выстрелит и не справиться с возросшей нагрузкой, то он просто будет не нужен. А хороших проектов мало.
0
Полностью согласен. Этот подход, скорее для начальных и не слишком объемных проектов. После усиленного роста некоторые переползают на ту же MongoDB. Хотя это конечно зависит от поставленой задачи
0
обычно лучший вариант — это тот, кода код может быстро получить номер сервера, к которому надо обращаться за данными. при такой реализации, при условии кеширования карты например в redis оверхед будет минимальным.
Я не уверен, что монге можно и нужно говорить что и куда она кладет. Вот допустим у вас пользователи и их друзья, допустим у вас сайт vk.com с их посещаемостью. если у вас список друзей будет «размазан» по серверам средствами БД, то вы рискуете получить неопределенное кол-во запросов к шардовым серверам. Если же вы храните друзей одного пользователя на одном сервере, то запрос будет всего один. Еще лучше, если вы сумеете хранить инфу о пользователе и его друзей на одно сервере — тогда профит будет вообще крутой. Это я все про большие нагрузки.
К чему я это — о нагрузках надо думать в самом начале, иначе рискуете нарваться на переписывание кода — это не надо никому.
Я не уверен, что монге можно и нужно говорить что и куда она кладет. Вот допустим у вас пользователи и их друзья, допустим у вас сайт vk.com с их посещаемостью. если у вас список друзей будет «размазан» по серверам средствами БД, то вы рискуете получить неопределенное кол-во запросов к шардовым серверам. Если же вы храните друзей одного пользователя на одном сервере, то запрос будет всего один. Еще лучше, если вы сумеете хранить инфу о пользователе и его друзей на одно сервере — тогда профит будет вообще крутой. Это я все про большие нагрузки.
К чему я это — о нагрузках надо думать в самом начале, иначе рискуете нарваться на переписывание кода — это не надо никому.
0
Разбиение графа на подграфы является NP-полной задачей.
0
Я видимо говорил не про то, что вы подумали, я про то, что если вы знаете номер пользователя, то несложно понять где он находится. Просто вы составляете карту типа такой: serverId spotId userIdFrom userIdTo. И очень быстро находите место нахождения пользователя.
0
наверно я неправильно понял, извиняюсь.
если стоит задача как-то хранить друзей, то наверно самый простой и быстрый вариант — хранить список друзей пользователя в поле(колонке) самого пользователя.
если стоит задача как-то хранить друзей, то наверно самый простой и быстрый вариант — хранить список друзей пользователя в поле(колонке) самого пользователя.
0
Postgres и сам справится с большими нагрузками, просто нужна правильная архитектура с горизонтальным масштабированием
0
>Это решение работает для моей ситуации, ваши требования могут быть другими,
>так что не стесняйтесь изменять, дополнять, калечить, истерически смеяться
>или копировать это для своих целей.
Слабое место постгреса — и оно было всегда — подобные вещи надо делать руками, и результат сильно зависит от квалификации. Этого быть не должно, СУБД потому и используют чтобы не писать свои велосипеды. Очень может оказаться, что дешевле для больших баз купить Oracle? получая поддержку, стандартизацию и готовых сертифицированных специалистов.
>так что не стесняйтесь изменять, дополнять, калечить, истерически смеяться
>или копировать это для своих целей.
Слабое место постгреса — и оно было всегда — подобные вещи надо делать руками, и результат сильно зависит от квалификации. Этого быть не должно, СУБД потому и используют чтобы не писать свои велосипеды. Очень может оказаться, что дешевле для больших баз купить Oracle? получая поддержку, стандартизацию и готовых сертифицированных специалистов.
-2
При партицировании (разбиении?) таблиц в PostgreSQL нужно обращать внимание на довольно жесткое ограничение количества партиций (унаследованных таблиц? разделов?). На практике, количество таких партиций не должно быть более 50-100 (по рекомендациям вычитанным в Инете). Это связано с работой планировщика запросов, который перебирает все разделы, чтобы решить, к каким обращаться, и делает это линейно. И для 100+ партиций, по отзывам, он работает не эффективно, и тормозит запросы.
Также (хотя про это никто не пишет), меня одолевают сомнения, как файловая система будет работать с каталогом, содержащим файлы базы данных PostgreSQL (каждая база — один каталог, в котором каждый файл — это одна таблица или индекс), если мы создадим 1,000 партиций какой-нибудь таблицы скажем с 4мя индексами — 5 файлов на партицию = 5,000 файлов — это на одну такую супер-таблицу.
Я планировал сначала такое дело для нашей базы — разбить данные по месяцам и по клиентам, но количество разделов на 10 лет получается порядка 100,000-1,000,000 :-) так что я эту идею бросил, и начал думать в направлении раскладывать клиентов в разные схемы+тэйблспэйсы, а каждого из них в его тэйблспэйсе уже бить по годам — тогда количество разделов получается разумное.
Также (хотя про это никто не пишет), меня одолевают сомнения, как файловая система будет работать с каталогом, содержащим файлы базы данных PostgreSQL (каждая база — один каталог, в котором каждый файл — это одна таблица или индекс), если мы создадим 1,000 партиций какой-нибудь таблицы скажем с 4мя индексами — 5 файлов на партицию = 5,000 файлов — это на одну такую супер-таблицу.
Я планировал сначала такое дело для нашей базы — разбить данные по месяцам и по клиентам, но количество разделов на 10 лет получается порядка 100,000-1,000,000 :-) так что я эту идею бросил, и начал думать в направлении раскладывать клиентов в разные схемы+тэйблспэйсы, а каждого из них в его тэйблспэйсе уже бить по годам — тогда количество разделов получается разумное.
-2
ну практика показывает что 35 тысяч таблиц (без учета индекса) вполне работоспособно. Но конечно всякости вылазят просто со всех сторон и автовакумов нужно много и планировщик местами тупит, но все таки при нормальном объеме памяти и числе ядер вполне живуче.
Насчет приведенной схемы решения: 2 проблемы: constraint exclusion вещь линейная и при большом числе партиций ( уже на паре десятков заметно) реально планировщик начинает тупить. Спасет конечно Prepared Statement но оно не учитывает значения параметров при планировании и тут уже просто может пострадать эффективность запросов.
Вторая проблема это собственно производительность триггеров: вставка просядет.
А насчет партиционирования из коробки аля Оракл. Он деньгов собственно стоит. Так что в халявной СУБД уровня постгресса врядли будет. Я Вот МПП хочу. в оракле он как самолет стоит.
Насчет приведенной схемы решения: 2 проблемы: constraint exclusion вещь линейная и при большом числе партиций ( уже на паре десятков заметно) реально планировщик начинает тупить. Спасет конечно Prepared Statement но оно не учитывает значения параметров при планировании и тут уже просто может пострадать эффективность запросов.
Вторая проблема это собственно производительность триггеров: вставка просядет.
А насчет партиционирования из коробки аля Оракл. Он деньгов собственно стоит. Так что в халявной СУБД уровня постгресса врядли будет. Я Вот МПП хочу. в оракле он как самолет стоит.
+2
У меня сотни таблиц работают и ничего. Опять же вещь специфичная, и как подчеркивается в статье наиболее применима к данным, теряющим актуальность со временем. В свое время писал аналогичную статью
+1
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Масштабирование производительности PostgreSQL с помощью партицирования таблиц