Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5   вперед  Ctrl      все
 Re: MySql vs Postgre vs ?  [new]
Arhat109
Member

Откуда: из СССР
Сообщений: 3430
РыбАлов В,

К сожалению, в рассмотрении только свободно распространяемый софт. Владелец/Заказчик - категорически против ЛЮБОЙ оплаты проприетарщикам. Он поддерживает только свободное распространение.
30 июл 12, 06:26    [12932597]     Ответить | Цитировать Сообщить модератору
 Re: MySql vs Postgre vs ?  [new]
Arhat109
Member

Откуда: из СССР
Сообщений: 3430
Сходу, можете пояснить как эти фичи могут оказаться полезны в решении поставленной задачи? Не очень понял нафига оно...
30 июл 12, 07:18    [12932626]     Ответить | Цитировать Сообщить модератору
 Re: MySql vs Postgre vs ?  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Arhat109
Arhat109, жаль нельзя исправить... дополню:

Вот ответ "надо переходить на..." - обязан сопровождаться объяснением ПОЧЕМУ эти задачи в этих условиях полезно решать другими средствами.
вам никто ничего не обязан, будьте благодарны каждому совету
30 июл 12, 09:54    [12932956]     Ответить | Цитировать Сообщить модератору
 Re: MySql vs Postgre vs ?  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

On 07/29/2012 09:26 PM, Ёш wrote:

> http://www.postgresql.org/docs/current/static/rules.html
> http://www.postgresql.org/docs/current/static/storage-toast.html

Ну это вообще не интересно. Если брать PG и MSSQL, то вообще
смысла нет сравнивать. Они вообще оного плана, одной
мощности. Но даже если сравнивать c MySQL для этой задачи думаю
всё равно что то, что это.

Posted via ActualForum NNTP Server 1.5

30 июл 12, 10:41    [12933196]     Ответить | Цитировать Сообщить модератору
 Re: MySql vs Postgre vs ?  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709


> Сходу: MatView, MatView-QueryRewrite, Intra-Query Parallelism, Compression,
> LogShipping, Transaction Replication, PWD... etc
> Можно ещё долго перечислять.

И оно ему надо для этой задачи?

Posted via ActualForum NNTP Server 1.5

30 июл 12, 10:41    [12933197]     Ответить | Цитировать Сообщить модератору
 Re: MySql vs Postgre vs ?  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709


> Вот ответ "надо переходить на..." - обязан сопровождаться объяснением ПОЧЕМУ эти
> задачи в этих условиях полезно решать другими средствами.

Вот если бы тебе граф расшивать запросом одним, вот это да, была бы фича в тему.

Кстати, в MSSQL есть WITH/CONNECT BY или как его там. Подходит для этой задачи.
В PG не знаю.

Posted via ActualForum NNTP Server 1.5

30 июл 12, 10:44    [12933216]     Ответить | Цитировать Сообщить модератору
 Re: MySql vs Postgre vs ?  [new]
rovan
Member

Откуда: Ставрополь
Сообщений: 387
MasterZiv,

В PG есть RECURSIVE CTE.
То же самое.
30 июл 12, 11:21    [12933405]     Ответить | Цитировать Сообщить модератору
 Re: MySql vs Postgre vs ?  [new]
Arhat109
Member

Откуда: из СССР
Сообщений: 3430
SergSuper, извиняюсь. Конечно надо было "полезно" вместо "обязательно". Просто хотел заметить, что отказ от перехода - может быть просто отказом, а предложение другого решения полезно обосновывать, в целом а не применительно к данной теме.

Вытаскивать всё поддерево одним (фиксированным) запросом даже в ситуации только parent_id - умею и на Мускуле. С переменными - не проблема, работает такой запрос максимум в три раза дольше чем динамически собранный union/join по уровню вложенности или выборка через отдельную таблицу связей... уже писал тут в теме про деревья на мускуле.

В принципе, тему можно закрывать. Для себя определил что остаюсь на Мускуле.
30 июл 12, 12:38    [12933891]     Ответить | Цитировать Сообщить модератору
 Re: MySql vs Postgre vs ?  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 11092
Arhat109
Вытаскивать всё поддерево одним (фиксированным) запросом даже в ситуации только parent_id - умею и на Мускуле

Интересно было бы посмотреть как. А то мне иногда такое требуется. Пока что приходится переносить для этого часть логики на PHP.
30 июл 12, 13:05    [12934138]     Ответить | Цитировать Сообщить модератору
 Re: MySql vs Postgre vs ?  [new]
tanglir
Member

Откуда:
Сообщений: 28966
Симонов Денис
Интересно было бы посмотреть как
Ну, вызов ХП - тоже запрос. Причём как раз один. И фиксированный к тому же :)
30 июл 12, 13:51    [12934535]     Ответить | Цитировать Сообщить модератору
 Re: MySql vs Postgre vs ?  [new]
miksoft
Member

Откуда:
Сообщений: 38919
Симонов Денис
Arhat109
Вытаскивать всё поддерево одним (фиксированным) запросом даже в ситуации только parent_id - умею и на Мускуле

Интересно было бы посмотреть как.
+1
30 июл 12, 14:06    [12934652]     Ответить | Цитировать Сообщить модератору
 Re: MySql vs Postgre vs ?  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 11092
tanglir
Ну, вызов ХП - тоже запрос.

А... Я то думал мало что пропустил.
30 июл 12, 14:20    [12934781]     Ответить | Цитировать Сообщить модератору
 Re: MySql vs Postgre vs ?  [new]
Alexander Dorogikh
Member

Откуда:
Сообщений: 10
поделюсь и своими соображениями.....

я с постгрес работал (наверно стоит сказать баловался) лет эдак 6-8 назад и все
тоесть ничерта уже не знаю и не помню

пред история
сейчас сервис работает на MySQL 5.1.52 (если мне не изменяет память), все таблици MyISAM, master+slave
сейчас БД занимает около 50ГБ, постоянно растет

после того как сдохла мать на одно из серверов, и позиция бинлога слейва опережала мастер ну очень прилично, а так же из-за того что восстановлени и запуск сервиса занял аж 6 часов времени, ни и естественно после того как директор вспомнил всех "лаского"...
было принято решение переехать на что то более стабильное, соответсвенно задались вопрос "а на что?"

сразу требования были такими
1. максимальная стабильность
2. синхронная репликация
3. легкость восстановления
4. отсутвие переделки кода, или сведение переделок к минимуму

я прошерстил мускульные решения и остановился на Percona XtraDB Cluster.
наш админ, был категорически против такого костыльного решение, цитирую не дословно )) "надстройка над дряхлой реализацией репликации в мускула". И предложил свою идею - "нафига нам такая глючная СУБД, давайте PostgreSQL ставить, есть много промышленых решений ....".
И еще стоит вспомнить то что обычно я на плюсы обращаю в последнию очередь, если решение подходит по требования, то мне куда интереснее знать минусы системы и с чем нам придеться столкнуться, чем знать всякие плюшки на которые и так никто не расчитывал. Посему в моих отчетах было больше высказано всяких бяк перконы (я с нее начал) чем преимуществ. На что админ "хватась за голову" кричал "нафига нам надо такое дерьмо, я в продакшн его не пущу, и вообще гарантий не даю"

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

Вообщем сошлись на том что нужно проверять/тестировать.

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

Для постгреса был выбран pgpool II, так как PGCluster умер вроде бы давно, вторую версию мы с админом так и не нашли. А ничто другое синхронную репликацию не поддерживает.

Почему начал с конца?
именно с возможности найти вменяемую свежую, обновляемую информацию по каждому и зрешений из какотото одного места. Тоесть сто бы создать кластер перконы мне понабоилось два ресурса, один из которых сам сайт перконы второй http://www.mysqlperformanceblog.com/, который и так ведут перконовци. Потом уже понадобилось куча других ресурсов, но то уже больше касалось понимания происходящих процессво и тонокого тюна.

Еще стоит отметить - что наш админ, сильно настаивал на том что не очень доверяет какимто продуктам и конторорам которые не дают сразу из коробки какогото полноценного решения. Витиевато сказал )). Я к тому что вот кластре перконы давал инфу как построить кластер, но не давал сриптов/программ/решений как полноценно мониторить кластер как автоматически правильно восстанавливать узел и пр.

Это в свою очередь добавило еще такое неявное условие к тестированию: оба кластера тестировались только с теми настройками которые рекомендовались для работы серверов в кластере. Никакого тонкого тюнинга не проводилось. Балансировщики также ни как тонко не настраивались. Вообщем такое себе "коробочное" решение.

И так некоторые данные из тестов:

+


баланесер HAProxy
AMD Phenom(tm) II X6 1055T Processor 2 ядра, 2.8 ГГц, 512МБ
percona-node1
AMD Phenom(tm) II X6 1055T Processor 2 ядра, 2.8 ГГц, 1024МБ
percona-node2
AMD Phenom(tm) II X4 945 Processor 2 ядра, 3,2 ГГц, 1024МБ
percona-node3
Intel(R) Core(TM)2 Duo CPU E6750 2 ядра, 2.66GHz, 1024МБ

чистый тест записи
min=0.0020556449890137
max=0.45267136891683
avg=0.004230509018898

чистый тест чтения
min=0.00086212158203125
max=0.028524160385132
avg=0.0030196107387543


баланесер pgpool2
AMD Phenom(tm) II X6 1055T Processor 2 ядра, 2.8 ГГц, 512МБ
postgres-node1
AMD Phenom(tm) II X6 1055T Processor 2 ядра, 2.8 ГГц, 1024МБ
postgres-node2
AMD Phenom(tm) II X4 945 Processor 2 ядра, 3,2 ГГц, 1024МБ
postgres-node3
Intel(R) Core(TM)2 Duo CPU E6750 2 ядра, 2.66GHz, 1024МБ

чистый тест записи
min=0.0054296652475993
max=0.14494268099467
avg=0.021722389920553

чистый тест чтения
min=0.0061240196228027
max=0.21231603622437
avg=0.011303532481194


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

далее админ сказал что неплохо было бы проверить LA при интенсивной записи, хотябы по top
поскольку нам нужна синхронная репликация, то масштабировать запись получаеться не сильно, тоесть нужно было проверить насколько движки серверов будут блоикровать остальную систему и самих себя

для данного теста были оставлены два узла, 6 ядерная машина была использована как гостевая для ВМ балансера, и создание тестовых процессов, на ней же поднята NFS, куда collectd писал свои наблюдения с узлов кластера.

условия
100 потоков
вставка в 3 таблици по 5000 строк
общее количство вставок 1500000

что имеем
+

кластер перконы
min=0.00771164894104
max=0.40158263842265
avg=0.027967720015844

percona-node2
percona-node3
тест завершился успешно за меньше чем 10 минут, я не поверил потом перепроверил еще два раза, все пучком по 500000 строк в каждой таблице

кластер постгрес
min=0.01076602935791
max=0.25553027788798
avg=0.043085272804896

postgres-node2
postgres-node3
а вот тут я задолюался ждать завершения
оставноил тест, на это время в каждой из таблиц находилось по 275029 строк
более того (скопипастил со своего отчета)

Я
вообщем както странно работало
100 потоков было создано мгоновенно
а вот pgpool сразу открыл соединений значительно меньше
две попытки входа на pgpool через psql провалились после 30 секунд ожидания

psql: server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.

(перкона в этом плане посзволяля заходить и смотреть статистику)
Отсюда получаеться что цифирки min/max/avg - актуальны ТОЛЬКО для скорости вставки, но не для наглядного представления работы приложения ибо не учитываеться время соединения с балансером


еще интересно то что la у постгреса значительно меньше получился на машине с более быстрым процессором - почему не знаю.


и снова небольшое резюме
графики load average - при сравнении кластеров не показательны
да у мускуля он выше, но мускул делает значительно больше работы чем тот постгрес, пишет данные, ведет бинлог, ведет кеш Галеры и еще кучу всего. И при этом отрабатывает запросы быстрее постгреса. Вот если опустить скорость до уровня постгреса, вот тогда можно было что то сказать более конкретно.

Восстановление

перкона - простовь добавь узел, если упало так что видно что будет трудно восстанавливать - добей (удали все), и покдлючи с нуля
постгрес - лично я (я не админ и не сильно хотел рыться во всем этом) так и не понял как сделать востановление, на момент написания моего отчета и этого текста, админ тоже не разобрался как его восстанавливать.

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

так же проверялось, но описывать уже не буду
- на сколько легко меняються струкутуры таблиц в двух решениях, и как это влияет на работу кластера
- также бегло было определено что перезд, именно переезд, существующего приложения на постргрес - вообще кактастрофа, просто так БД не конвертируешь, часть кода придеться менять точно.
- писать приложение с нуля на постгрес можно, хотя все таки меня смущает вопрос производительности. Так же у постгреса более развитый язык описания функций/процедур, и много вкусных плюшек в типах данных и ограничениях, но это уже....другая история вообщем то.

хочеться услышать ваше ФИ по моему тексту
30 июл 12, 16:15    [12935701]     Ответить | Цитировать Сообщить модератору
 Re: MySql vs Postgre vs ?  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709


> 2. синхронная репликация

Синхронной репликации не бывает.
Синхронная репликация называется "распределённая транзакция".

Posted via ActualForum NNTP Server 1.5

30 июл 12, 17:58    [12936407]     Ответить | Цитировать Сообщить модератору
 Re: MySql vs Postgre vs ?  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

On 07/30/2012 05:15 PM, Alexander Dorogikh wrote:
> Начну с конца, тоесть с того вывода который я сам для себя сделал в самый
> последний момент
> это "промышленность решения"
> с одной стороны это означает что данноя штука уже давным давно используеться в
> продакшн, а с другой
> Перкона - контора которая промышленно занимаеться разработкой, продукт постоянно
> развиваеться, ведет продвижение в массы, тех поддержку и пр.

Она не занимается разработкой. Перкона только патчит стандартный MySQL добавляя
туда какие-то нужные фичи и леча серьёзные баги.

Отношение MySQL - Percona примерно как kernel dev team -- Red Hat.
Роли примерно такие же.

И техподдержка у них, что естественно, за деньги.
Такую же поддержку можно заказать и в самом MySQL.

Ну и перконовскому клону не так много лет.

> "поделки постгреса" - написано вроде валом, вроде в продакшене работают, но
> никто ни за что не отвечает. Ну окромя skytools, но она нам не подходила так как
> имела асинхронную репликацию.

В сообществе Postgres есть точно такой же EnterpriseDB, который делает ровно
то же самое -- даёт поддержку Postgres, патчит баги, имеет свои суперфичи.


Posted via ActualForum NNTP Server 1.5

30 июл 12, 18:04    [12936449]     Ответить | Цитировать Сообщить модератору
 Re: MySql vs Postgre vs ?  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

On 07/30/2012 05:15 PM, Alexander Dorogikh wrote:
> И так некоторые данные из тестов:

> чистый тест записи
> min=0.0020556449890137
> max=0.45267136891683
> avg=0.004230509018898
>
> чистый тест чтения
> min=0.00086212158203125
> max=0.028524160385132
> avg=0.0030196107387543

> чистый тест записи
> min=0.0054296652475993
> max=0.14494268099467
> avg=0.021722389920553
>
> чистый тест чтения
> min=0.0061240196228027
> max=0.21231603622437
> avg=0.011303532481194
>
>
>
> все перечисленные конфиги относяться к виртуалкам запущеным на офисных (вообщем
> даже домашних) машинах.

Вы сравнивали транзакционный Postgres и нетранзационный MySQL+MyISAM ?

Posted via ActualForum NNTP Server 1.5

30 июл 12, 18:08    [12936481]     Ответить | Цитировать Сообщить модератору
 Re: MySql vs Postgre vs ?  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709
Alexander Dorogikh
хочеться услышать ваше ФИ по моему тексту


Извини за прямоту, вы просто зря потратили время.
Тестирование СУБД -- это очень непростое дело, и что два сдуру сунувшихся в это дело
человека покажут что-то путное в виде результатов -- это абсолютно невероятное событие.
30 июл 12, 18:13    [12936508]     Ответить | Цитировать Сообщить модератору
 Re: MySql vs Postgre vs ?  [new]
Alexander Dorogikh
Member

Откуда:
Сообщений: 10
то что перкона патчит эт я знаю, можно увидеть самому когда собирать перокону и тянуть из дистрибов
но все таки это официальное лицо которое поставлет Percona XtraDB Cluster
EnterpriseDB - дает какоето бесплатное кластерное решение? я серьезно спрашиваю

распереденная транзакция это подноготная происходящего процесса, но почему почти везде и на та же перкона имено так и называет свою репликацию синхронной (http://www.percona.com/software/percona-xtradb-cluster/)



MasterZiv
Вы сравнивали транзакционный Postgres и нетранзационный MySQL+MyISAM ?


мы сранивали постргес и перкону с ее движком поумолчанию XtraDB

MasterZiv
Извини за прямоту, вы просто зря потратили время.
Тестирование СУБД -- это очень непростое дело, и что два сдуру сунувшихся в это дело
человека покажут что-то путное в виде результатов -- это абсолютно невероятное событие.


прямота не тсрашна, а бы поделу
наш сервис работает на рынке уже в течении 7 лет так что не совсем сдуру
я понимаю что толком мы ничего не тестировали и о том что мы тратим время я пытался доказать, но увы....
хотя если деньги платяться...... то почему бы не потестить

я даже по секрету скажу -
+
вся эта бодяга больше для того что бы остановить выбор на перконе

постгрес хоть и знаком админу, но как его тюнинговать, как вообще им пользоваться )) в компании никто не знает, я сам 6 лет мускулом пользуюсь, мож не знаю абсолютно всего, но 6 лет это и так не мало ))) (хочеться так думать)

и все таки результат как бы есть
переход на перкону как минимум не ухудшит производительности (с учетом того что текущиее решение тюнинговалось 6 лет, а перкона запускалась с "дефолтными" настройками). Да и переход будет безболезненным с минимальным временем простоя сервиса.

на данный момент мы просто не увидели сильных преимуществ постгреса на майскул "с патчами от перконы ))"

если я что то упустил, серьезное, с удовольствием выслушаю
30 июл 12, 19:26    [12936822]     Ответить | Цитировать Сообщить модератору
 Re: MySql vs Postgre vs ?  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54789

Alexander Dorogikh
почему почти везде и на та же перкона имено так и называет свою
репликацию синхронной

Потому что все и всегда её так называют, только Баба Яга MasterZiv - против.

Posted via ActualForum NNTP Server 1.5

30 июл 12, 19:42    [12936890]     Ответить | Цитировать Сообщить модератору
 Re: MySql vs Postgre vs ?  [new]
Yo.!
Guest
1.5M записей 10 минут ... как-то не впечатляет перфоменс. а сколько стооит эта перкона на такие 4 ноды ?
30 июл 12, 19:43    [12936892]     Ответить | Цитировать Сообщить модератору
 Re: MySql vs Postgre vs ?  [new]
Alexander Dorogikh
Member

Откуда:
Сообщений: 10
Yo.!
1.5M записей 10 минут ... как-то не впечатляет перфоменс. а сколько стооит эта перкона на такие 4 ноды ?

пока нисколько
все тестировалось на VirtaulBox машинах, проыцессор и память указаны в результатах
тюнингом никто не занимался

такой вопрос - а какой показатель считать впечатляющим?

(мы принципе сейчас находиммся на этапе реорганизации сервиса, часть операций вообще уйдет в NoSQL, там где именно важна скорость засписи а не целостность данных)
30 июл 12, 19:59    [12936937]     Ответить | Цитировать Сообщить модератору
 Re: MySql vs Postgre vs ?  [new]
Alexander Dorogikh
Member

Откуда:
Сообщений: 10
Yo.!
1.5M записей 10 минут ... как-то не впечатляет перфоменс. а сколько стооит эта перкона на такие 4 ноды ?


зыж
и еще
она вообще бесплатна, платна только поддержка (срочная если нужно очень)
а про пока нисколько - я имел ввиду аренду шелезяк

рекомендуеться нечетное число узлов для того что бы галера могла нормально решить проблему split brain (мы пока остановились на 3х серверах)
кстати я так и не понял как с этим обстоят дела у pgpool
30 июл 12, 20:13    [12936985]     Ответить | Цитировать Сообщить модератору
 Re: MySql vs Postgre vs ?  [new]
Arhat109
Member

Откуда: из СССР
Сообщений: 3430
miksoft,

Сожалею, но не могу привести SQL. Идея - проста, заметьте что:

1. простой джойн таблицы сама с собою - дает все связи всех узлов всех деревьев (без части where).
2. если таблицу правильно проиндексировать, то можно обеспечить требуемый порядок выборки этих связей.
3. остается только организовать "память" о подузлах на переменных (и это оказывается очень дешево и крайне быстро у Мускуля!).

Всё. На выход отдаем только требуемые подузлы частью where.
30 июл 12, 20:49    [12937092]     Ответить | Цитировать Сообщить модератору
 Re: MySql vs Postgre vs ?  [new]
Alexander Dorogikh
Member

Откуда:
Сообщений: 10
http://www.enterprisedb.com/solutions/mysql-vs-postgresql
вот такие высокопарные слова, а реальных данных для сравнениея нема
админ тоже так задушевно )) рассказывал о преимуществах но так и не привел никаких толковых аргументов

на данный момент из того что нам требуеться я нашел только вот это
http://www.enterprisedb.com/products-services-training/products/postgres-plus-advanced-server
но сколько оно стоит???
30 июл 12, 21:39    [12937247]     Ответить | Цитировать Сообщить модератору
 Re: MySql vs Postgre vs ?  [new]
Arhat109
Member

Откуда: из СССР
Сообщений: 3430
Alexander Dorogikh,

Спасибо за приведенные данные. Пусть они и "пол-потолок-палец", но по крайней мере не увидел солидных аргументов "за" переход с Мускуля куда-то ещё для своей задачи.
30 июл 12, 22:15    [12937391]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить