MySQL 5.6 или PostgreSQL 9.4

Кстати как у слоника обстоит с горизонтальным партицированием?
Слышал там это дело просто эмулируется

Ну "эмулируется" - не совсем верное слово, но такого как в mysql (все спрятано внутрях) там нет.

В Постгресе есть наследование таблиц и constraints на таблицу. На базе этого и построено партицирование, т.е. создаются таблицы "наследники" от базовой таблицы с указанием - какой диапазон данных туда пихать. Но поскольку это получаются как бы разные таблицы, если мы хотим единую точку входа для работы с партициями, то нужен обвес из тригеров. В общем может быть довольно гиморно, хотя есть готовые расширения по созданию партиций и обвеса.

С другой стороны партиция-как-таблица позволяет, например, создавать разные наборы индексов на разные партиции.

И еще следует отметить, что часть задач, которые в mysql решается партициями (уменьшение размера индекса), в postgres решается частичными индексами и никаких партиций не нужно.

(Отредактировано автором: 27 Мая, 2015 - 12:27:15)

-----
self-banned

Ну тогда если я верно понимаю то частичные индексы хороши как покрывающие
А вот для псевдослучайного доступа к остальным данным огромной таблицы не помещающейся в памяти (а иначе зачем партицирование) они не особо и помогут
Не?

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

Вот если есть ярко выраженные горячие и холодные данные, то помогает. Но и частичный индекс поможет - на горячие данные. А для холодных будет фулскан, ну или второй индекс построить можно.


Не, преимущества нормального партицирования есть, конечно, особо если партиции разносить по дискам разным. Так что тут есть куда постгресу двигаться. Но не то, что бы киллер-фича, партиции вообще не часто используют, и чаще всего что бы уменьшить размер индекса как раз.

-----
self-banned

Нене
Допустим частичный индекс влезает в память
Только вот если он не покрывающий то придется лезть на диск за данными
А вот у мускула и данные находятся в небольшой таблице
И значит вся таблица скорее всего уже в памяти
А у слоника даже при частичном индексе по горячим данным придется за ними на диск лазать
Не?
(Добавление)
Под псевдослучайным доступом я имел ввиду антоним последовательного
Для которого обращение к диску не проблема

Да, тут вы правы, в таких случаях скорее всего партицирование нужно. Хотя если честно я не очень вкурсе, что там кешируется в памяти из данных и по какому принципу ;) Нужно погуглить или потестировать как себя такие случаи вести будут.

Да в общем партицирование через наследование тоже вполне рабочее решение. Может не очень красивое, но рабочее, а если использовать готовые расширения (которые создают всякие тригеры и вьюхи), то и не сложное.

-----
self-banned

Ну да
Но в любом случае серебрянной пули не бывает
Я бы убил пару выходных и проштудировал всякие mysql vs postgresql
Глядишь и узнаешь что удобнее под конкретный проект
Хотя подозреваю что postgres))