[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: Postgres: насколько мощный?
kirik
Привет всем!

Сразу оговорюсь, вопрос не ради холивара mysql vs postgres, а ради получения данных о работе PG под нагрузкой.

Имеется веб-проект - соц.сеть. Сейчас работает на mysql+myisam и при количестве онлайнеров > 250-300 (реальных запросов где-то 30/с) БД отказывался работать smile.gif Запросы и структура были оптимизированы насколько только можно, стал "вываливаться" 300-350. Потом к самым "труднодоступным" (на выборку) местам был прекручен memcached - планка поднялась до 350-400. Потом были найдены пара мест, где довольно часто обновлялись данные в одной из таблиц (из нее же шли постоянные селекты), перенес обновление тоже на memcache - теперь вываливается при 500. Пробовал перевести эту большую и активную табличку на innodb, но меня ждало разочарование - селекты стали еще медленнее (хотя теоретически должно было все остаться так же хотя бы, т.к. innodb лочит не таблицу а строку при изменениях).

Отсюда вопрос: поможет ли мне posgres? Или все-таки передумывать структуру проекта..?

ЗЫ. нужны реальные цифры/данные, а не "я слышал что посгрес тормозит".
ЗЫ2. читал много обзоров и сравнений, по ощущениям PG должен помочь, но хотелось бы услышать ваше мнение (sergiss'а особенно, у тебя там многомиллионные таблички smile.gif )



Спустя 6 минут, 34 секунды (8.11.2010 - 10:45) Семён написал(а):
Kirik вспомни, что Facebook работал до недавнего времени на mySQL.
Смотри в сторону MongoDB лучше, правда она выигрывает у мускуля только на Insert-ах, PostgreSQL рассматривать вообще бы на мой взгляд не стоило бы. smile.gif
Если волнуют цифры, то это только относительно сложности твоих запросов к базе, выборка на простых запросах MySQL будет быстрее чем PostgreSQL, в чём проблема произвести сравнение?

Спустя 1 час, 23 минуты, 1 секунда (8.11.2010 - 12:08) sergeiss написал(а):
Цитата (kirik @ 8.11.2010 - 11:38)
читал много обзоров и сравнений, по ощущениям PG должен помочь, но хотелось бы услышать ваше мнение (sergiss'а особенно, у тебя там многомиллионные таблички smile.gif)

Как поётся в одной известной песне "я вам не скажу за всю Одессу..." smile.gif Вопрос достаточно абстрактный, чтобы я мог на него ответить. Тут надо иметь 2 БД с одинаковыми данными, MySQL и Postgre, гонять там одни и те же запросы и смотреть.

У меня да, очень большие таблицы. Но запросов в единицу времени не так и много. Скорее даже так: большей частью "тяжелые" запросы, которые выполняются достаточно нечасто. Нормальный средний период между запросами, по статистике, порядка 3-4 секунд. Это когда один человек работает. Он жмякает кнопку на форме, данные запрашиваются, формируется страница. Человек оценивает картинку (график), после чего жмёт "следующий день", или "предыдущий день", или "другой TRX".
Редко когда двое людей одновременно там работают. За день если 15-20 юзеров наберётся - то уже хорошо smile.gif

Короче говоря... На заданный тобой вопрос я не могу ответить при всём желании. Только если как-то помочь при тестировании скорости работы в Постгре. Может быть, как-то помогу в переделывании запросов под Постгре, чтобы учесть его специфику.

Спустя 6 минут, 38 секунд (8.11.2010 - 12:14) twin написал(а):
У меня обычный мускул без мемкэша тянет гораздо большую нагрузку.
Странно даже. Может там запросы сумашедшие?

Спустя 8 минут, 22 секунды (8.11.2010 - 12:23) Семён написал(а):
Цитата (twin @ 8.11.2010 - 13:14)
У меня обычный мускул без мемкэша тянет гораздо большую нагрузку.
Странно даже. Может там запросы сумашедшие?

Например как в 1С Битрикс smile.gif

SELECT DISTINCT BE.ID as ID,BE.NAME as NAME,BE.CODE as CODE,BE.IBLOCK_ID as
IBLOCK_ID,BE.IBLOCK_SECTION_ID as IBLOCK_SECTION_ID,B.DETAIL_PAGE_URL as
DETAIL_PAGE_URL,BE.DETAIL_TEXT as DETAIL_TEXT,BE.DETAIL_TEXT_TYPE as
DETAIL_TEXT_TYPE,BE.DETAIL_PICTURE as DETAIL_PICTURE,BE.PREVIEW_TEXT as
PREVIEW_TEXT,BE.PREVIEW_TEXT_TYPE as PREVIEW_TEXT_TYPE,BE.PREVIEW_PICTURE as
PREVIEW_PICTURE,L.DIR as LANG_DIR,BE.XML_ID as EXTERNAL_ID,B.IBLOCK_TYPE_ID as
IBLOCK_TYPE_ID,B.CODE as IBLOCK_CODE,B.XML_ID as IBLOCK_EXTERNAL_ID FROM
b_iblock B INNER JOIN b_lang L ON B.LID=L.LID INNER JOIN b_iblock_element BE
ON BE.IBLOCK_ID = B.ID INNER JOIN b_iblock_section_element BSE ON
BSE.IBLOCK_ELEMENT_ID = BE.ID INNER JOIN b_iblock_section BSubS ON
BSE.IBLOCK_SECTION_ID = BSubS.ID INNER JOIN b_iblock_section BS ON
(BSubS.IBLOCK_ID=BS.IBLOCK_ID AND BSubS.LEFT_MARGIN>=BS.LEFT_MARGIN AND
BSubS.RIGHT_MARGIN<=BS.RIGHT_MARGIN) INNER JOIN b_iblock_property FP1 ON
FP1.IBLOCK_ID=B.ID AND FP1.CODE='code2' INNER JOIN b_iblock_element_property
FPV1 ON FP1.ID=FPV1.IBLOCK_PROPERTY_ID AND FPV1.IBLOCK_ELEMENT_ID=BE.ID INNER
JOIN
b_iblock_property FP2 ON FP2.IBLOCK_ID=B.ID AND FP2.CODE='code3' INNER
JOIN
b_iblock_element_property FPV2 ON FP2.ID=FPV2.IBLOCK_PROPERTY_ID AND
FPV2.IBLOCK_ELEMENT_ID=BE.ID INNER JOIN b_iblock_property FP3 ON
FP3.IBLOCK_ID=B.ID AND FP3.CODE='code4' INNER JOIN b_iblock_element_property
FPV3 ON FP3.ID=FPV3.IBLOCK_PROPERTY_ID AND FPV3.IBLOCK_ELEMENT_ID=BE.ID INNER
JOIN
b_iblock_property FP4 ON FP4.IBLOCK_ID=B.ID AND FP4.CODE='code5' INNER
JOIN
b_iblock_element_property FPV4 ON FP4.ID=FPV4.IBLOCK_PROPERTY_ID AND
FPV4.IBLOCK_ELEMENT_ID=BE.ID INNER JOIN b_iblock_property FP5 ON
FP5.IBLOCK_ID=B.ID AND FP5.CODE='code7' INNER JOIN b_iblock_element_property
FPV5 ON FP5.ID=FPV5.IBLOCK_PROPERTY_ID AND FPV5.IBLOCK_ELEMENT_ID=BE.ID INNER
JOIN
b_iblock_property FP6 ON FP6.IBLOCK_ID=B.ID AND FP6.CODE='code9' INNER
JOIN
b_iblock_element_property FPV6 ON FP6.ID=FPV6.IBLOCK_PROPERTY_ID AND
FPV6.IBLOCK_ELEMENT_ID=BE.ID INNER JOIN b_iblock_property FP7 ON
FP7.IBLOCK_ID=B.ID AND FP7.CODE='code12' INNER JOIN b_iblock_element_property
FPV7 ON FP7.ID=FPV7.IBLOCK_PROPERTY_ID AND FPV7.IBLOCK_ELEMENT_ID=BE.ID INNER
JOIN
b_iblock_property FP8 ON FP8.IBLOCK_ID=B.ID AND FP8.CODE='code15' INNER
JOIN
b_iblock_element_property FPV8 ON FP8.ID=FPV8.IBLOCK_PROPERTY_ID AND
FPV8.IBLOCK_ELEMENT_ID=BE.ID INNER JOIN b_iblock_property FP9 ON
FP9.IBLOCK_ID=B.ID AND FP9.CODE='code16' INNER JOIN b_iblock_element_property
FPV9 ON FP9.ID=FPV9.IBLOCK_PROPERTY_ID AND FPV9.IBLOCK_ELEMENT_ID=BE.ID INNER
JOIN
b_iblock_property FP10 ON FP10.IBLOCK_ID=B.ID AND FP10.CODE='code18'
INNER JOIN b_iblock_element_property FPV10 ON FP10.ID=FPV10.IBLOCK_PROPERTY_ID
AND FPV10.IBLOCK_ELEMENT_ID=BE.ID INNER JOIN b_iblock_property FP11 ON
FP11.IBLOCK_ID=B.ID AND FP11.CODE='code23' INNER JOIN
b_iblock_element_property FPV11 ON FP11.ID=FPV11.IBLOCK_PROPERTY_ID AND
FPV11.IBLOCK_ELEMENT_ID=BE.ID INNER JOIN b_iblock_property FP12 ON
FP12.IBLOCK_ID=B.ID AND FP12.CODE='code26' INNER JOIN
b_iblock_element_property FPV12 ON FP12.ID=FPV12.IBLOCK_PROPERTY_ID AND
FPV12.IBLOCK_ELEMENT_ID=BE.ID INNER JOIN b_iblock_property FP13 ON
FP13.IBLOCK_ID=B.ID AND FP13.CODE='code27' INNER JOIN
b_iblock_element_property FPV13 ON FP13.ID=FPV13.IBLOCK_PROPERTY_ID AND
FPV13.IBLOCK_ELEMENT_ID=BE.ID INNER JOIN b_iblock_property FP14 ON
FP14.IBLOCK_ID=B.ID AND FP14.CODE='code32' INNER JOIN
b_iblock_element_property FPV14 ON FP14.ID=FPV14.IBLOCK_PROPERTY_ID AND
FPV14.IBLOCK_ELEMENT_ID=BE.ID INNER JOIN b_iblock_property FP15 ON
FP15.IBLOCK_ID=B.ID AND FP15.CODE='code34' INNER JOIN
b_iblock_element_property FPV15 ON FP15.ID=FPV15.IBLOCK_PROPERTY_ID AND
FPV15.IBLOCK_ELEMENT_ID=BE.ID WHERE 1=1 AND B.ID IN (0,42) AND (
(
BE.WF_STATUS_ID=1 AND BE.WF_PARENT_ELEMENT_ID IS NULL) ) AND ((((
(
upper(BE.NAME) like upper('%acer7730G%') and BE.NAME is not null) )))) AND
(((( (upper(FPV1.VALUE) like upper('%Intel%') and FPV1.VALUE is not null) AND
(upper(FPV1.VALUE) like upper('%Core2Duo%') and FPV1.VALUE is not null) AND
(upper(FPV1.VALUE) like upper('%T5850%') and FPV1.VALUE is not null) AND
(upper(FPV1.VALUE) like upper('%2.16GHz%') and FPV1.VALUE is not null) ))))
AND (((( (upper(FPV2.VALUE) like upper('%4096Mb%') and FPV2.VALUE is not null)
AND ( (upper(FPV2.VALUE) like upper('%4Gb%') and FPV2.VALUE is not null) ) AND
(upper(FPV2.VALUE) like upper('%DDRII%') and FPV2.VALUE is not null) )))) AND
(((( (upper(FPV3.VALUE) like upper('%2x320Gb%') and FPV3.VALUE is not null)
AND (upper(FPV3.VALUE) like upper('%5400rpm%') and FPV3.VALUE is not null) AND
(upper(FPV3.VALUE) like upper('%SATA%') and FPV3.VALUE is not null) )))) AND
(((( (upper(FPV4.VALUE) like upper('%17%') and FPV4.VALUE is not null) ))))
AND (((( (upper(FPV5.VALUE) like upper('%??%') and FPV5.VALUE is not null)
))))
AND (((( (upper(FPV6.VALUE) like upper('%64Mb%') and FPV6.VALUE is not
null
) AND ( (upper(FPV6.VALUE) like upper('%??%') and FPV6.VALUE is not null)
AND (upper(FPV6.VALUE) like upper('%958Mb%') and FPV6.VALUE is not null) )))))
AND (((( (upper(FPV7.VALUE) like upper('%??%') and FPV7.VALUE is not null)
))))
AND (((( (upper(FPV8.VALUE) like upper('%Bluetooth%') and FPV8.VALUE is
not null
) AND (upper(FPV8.VALUE) like upper('%V2.0%') and FPV8.VALUE is not
null
) AND (upper(FPV8.VALUE) like upper('%EDR%') and FPV8.VALUE is not null)
))))
AND (((( (upper(FPV9.VALUE) like upper('%4%') and FPV9.VALUE is not null)
))))
AND (((( (upper(FPV10.VALUE) like upper('%??%') and FPV10.VALUE is not
null
) )))) AND (((( (upper(FPV11.VALUE) like upper('%??%') and FPV11.VALUE is
not null
) )))) AND (((( (upper(FPV12.VALUE) like upper('%??%') and FPV12.VALUE
is not null) )))) AND (((( (upper(FPV13.VALUE) like upper('%WebCam%') and
FPV13.VALUE is not null) AND (upper(FPV13.VALUE) like upper('%1,3Mpx%') and
FPV13.VALUE is not null) )))) AND (((( (upper(FPV14.VALUE) like
upper('%?????%') and FPV14.VALUE is not null) )))) AND ((((
(
upper(FPV15.VALUE) like upper('%12%') and FPV15.VALUE is not null) AND
(upper(FPV15.VALUE) like upper('%???????%') and FPV15.VALUE is not null) ))))
AND ((((BE.IBLOCK_ID = '42')))) AND (((BE.ACTIVE_TO >= now() OR BE.ACTIVE_TO
IS NULL) AND (BE.ACTIVE_FROM <= now() OR BE.ACTIVE_FROM IS NULL))) AND
((((BE.ACTIVE='Y')))) AND ((BS.ID = 224)) ORDER BY BE.SORT asc , BE.ID desc
LIMIT
0, 30

Спустя 15 минут, 26 секунд (8.11.2010 - 12:38) DedMorozzz написал(а):
Этим запросом - можно убить....

Спустя 9 минут, 40 секунд (8.11.2010 - 12:48) sergeiss написал(а):
"Ой, мама, что это?" blink.gif

А может, тут где-то можно сделать некие промежуточные таблицы?
Например, ты тут теряешь немало времени на преобразованиях в верхний регистр. Что в MySQL это будет, что в Постгре. И делается сие преобразование для многих строчек.
Либо сделать не промежуточную таблицу, а дополнительные поля в той же таблице. В одном поле - оригинальная строка, в другом - она же в верхнем регистре. Мне так сдаётся, что это существенно ускорит процесс выборки. За счет выключения из работы функции upper().
Хотя, конечно, это и увеличит объём базы smile.gif Но тут уж выбирай: или скорость, или объём.

PS. Да еще и джойнов куча целая... Конечно, он будет тормозить, твой запрос smile.gif В детали запроса я не вникал, честно говоря, потому что много всего тут.

Насчет джойнов я напишу свои соображения чуть попозже, пообедать надо сходить smile.gif Через минут 30-40-50 напишу.

Спустя 4 минуты, 16 секунд (8.11.2010 - 12:52) Семён написал(а):
sergeiss
Это пример из кода движка 1С Битрикс.
Это к вопросу kirika вида запроса для сравнения на базах MySQL, PostgreSQL

Спустя 17 минут, 42 секунды (8.11.2010 - 13:10) sergeiss написал(а):
Семён, kirik - сорри, я мальца попутал, кто и что написал smile.gif Мои соображения от этого не изменяются (приведенный пример запроса не очень-то "красивый" и очень неоптимальный). Но ждём-с пока, что ТС скажет насчет своих запросов.

Спустя 7 часов, 9 минут, 2 секунды (8.11.2010 - 20:19) kirik написал(а):
Цитата (Семён @ 8.11.2010 - 02:45)
Смотри в сторону MongoDB лучше, правда она выигрывает у мускуля только на Insert-ах

Очень красиво смотрится MongoDB, слишком красиво чтобы быть правдой smile.gif

Цитата (Семён @ 8.11.2010 - 02:45)
в чём проблема произвести сравнение?

Лень smile.gif Думал может у кого есть данные из жизни. Ну раз нет, придется тестить mysql-postgres-mongo

Цитата (sergeiss @ 8.11.2010 - 04:08)
Может быть, как-то помогу в переделывании запросов под Постгре, чтобы учесть его специфику.

Пожалуй будут вопросы smile.gif Ибо почитав мануал по postgres'у стало понятно, что там все иначе чем в mysql smile.gif

Цитата (twin @ 8.11.2010 - 04:14)
У меня обычный мускул без мемкэша тянет гораздо большую нагрузку.
Странно даже. Может там запросы сумашедшие?

Я вот тоже не думал что mysql такой хилый.. Запросы обычные, максимум 4 джоина, explain нормальный (большинство запросов проходит по индексам, у пары таблиц индексы пришлось убить из-за тормозящей вставки).. может у меня че с сервером не то... или с головой, правда smile.gif

Спустя 13 минут, 49 секунд (8.11.2010 - 20:32) twin написал(а):
Джоины она сильно не любит под большими нагрузками, по крайней мере из моего опыта. Два подряд запроса переносятся куда легче.
По крайней мере мне пришлось запросы с ними переписывать (достались от предшественника).


Спустя 11 минут, 19 секунд (8.11.2010 - 20:44) kirik написал(а):
Цитата (twin @ 8.11.2010 - 12:32)
Джоины она сильно не любит под большими нагрузками, по крайней мере из моего опыта.

Я как-то тест на локалхосте проводил - разница была не сильно большая. Гм.. а может да.. в памяти создается сджоинная таблица, т.к запросов разных много, память отжарается мгновенно и ее не хватает для остальных запросов.. Интересно. Сегодня попробую "разджоинить" запросы.
Хе) и вот возникает вопрос - столо ли когда-то учиться JOIN'у, чтобы потом выполнять простые запросы..? smile.gif

Спустя 13 часов, 6 минут, 17 секунд (9.11.2010 - 09:50) sergeiss написал(а):
Насчет джойнов... Вот какие есть соображения. Из опыта.

Вот, допустим, делаю простейший джойн (синтаксис из Постгре!), с некоторыми условиями
(1)
select * from table1
full join table2
using (id)
where <условие>


Этот же запрос можно чуть по-другому переписать
(2)
select * from (select * from table1 where <условие>)
full join (select * from table2 where <условие>)
using (id)


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

В случае простых таблиц и при правильно выставленных индексах первая и вторая выборки делаются за одно и то же время, что кажется вполне логичным.
Но как только начинаются какие-то усложнения, например, выбора идет не из простой таблицы, а из другой выборки (которая тоже не особо простая), либо используются какие-то функции, то тут уже есть разница. Второй вариант выборки может оказаться существенно быстрее, иногда вместо десятков (сотен) секунд, на очень больших таблицах (десятки миллионов записей), получаем уменьшение времени выборки до десятых (сотых) ДОЛЕЙ СЕКУНДЫ. Но даже если, в крайнем случае, вместо 500 секунд я получаю 5 секунд, то уже хорошо smile.gif
С чем это связано? Могу только предположить, что это из-за того, что в каких-то промежуточных выборках просто нету индексов. И если там очень много вариантов, то и время увеличивается весьма существенно. Если же количество строк ограничиваем изначально, то даже при отсутствии индексов процесс идет быстро. Это мои предположения, не более того. Но факт такой есть.

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

Спустя 12 минут, 11 секунд (9.11.2010 - 10:02) twin написал(а):
Цитата
и вот возникает вопрос - столо ли когда-то учиться JOIN'у, чтобы потом выполнять простые запросы..?
В PHP такое сплошь и рядом.
Те же паттерны взять. Нет, чтобы назвать нормально - костыли. smile.gif

Это что за хрень вообще - синглетон. То есть нужно выучить кучу всякого дерьма, чтобы потом, не дай Бог, не заблудиться в собственном коде... smile.gif

А с джоинами так и есть. Лочатся запросы с ними и пипец. Мускул down.

Спустя 1 час, 29 минут, 14 секунд (9.11.2010 - 11:31) Семён написал(а):
Цитата (kirik @ 8.11.2010 - 21:19)
Цитата (Семён @ 8.11.2010 - 02:45)
в чём проблема произвести сравнение?

Лень smile.gif Думал может у кого есть данные из жизни. Ну раз нет, придется тестить mysql-postgres-mongo

Сравнение чего? BMW x5 и Ламборджинии? Смотря какие условия езды... Есть конкретный запрос, есть конкретное сравнение.

Спустя 10 часов, 38 минут, 12 секунд (9.11.2010 - 22:10) kirik написал(а):
sergeiss
Очень уж в mysql подзапросы кривые, будет еще хуже smile.gif

Цитата (Семён @ 9.11.2010 - 03:31)
Смотря какие условия езды... Есть конкретный запрос, есть конкретное сравнение.

Эт понятно smile.gif В веб проектах просто чаще всего приходится работать с подобными видами запросов: юзер-пост-комменты.

Спустя 9 часов, 25 минут, 37 секунд (10.11.2010 - 07:35) kirik написал(а):
Провел тест postgres и mysql (myisam и innodb) на своей "трудной" табличке. Взял самый простой запрос.
Немного результатов (запросы будут одинаковые для обоих, только у mysql в тестах для честности был добавлен SQL_NO_CACHE после SELECT):
Уникальный индекс: post_id
Запросы:
SELECT *
FROM links_posts AS p
ORDER BY p.post_id DESC
LIMIT
11 OFFSET 333

myisam: 0.006
innodb: 0.007
postgres: 0.015
SELECT *
FROM links_posts AS p
ORDER BY p.post_id DESC
LIMIT
11 OFFSET 10000

myisam: 0.12
innodb: 0.36
postgres: 0.035 !
SELECT *
FROM links_posts AS p
ORDER BY p.post_id DESC
LIMIT
11 OFFSET 100000

myisam: 1.195
innodb: 3.894
postgres: 0.178 !!!

Вывод: чем дальше мы уходим от начала таблички тем сложнее mysql дается limit. А innodb вообще сосет, хоть у него есть свои плюсы.

PS. и mysql и postgres были испытаны с настройками по умолчанию.
PS2. записей в табличке 200к

Спустя 57 минут, 25 секунд (10.11.2010 - 08:33) kirik написал(а):
sergeiss, никак не могу найти информацию по поводу блокироки в PG.. При изменении строки в таблице заблокируется вся таблица (как в myisam) или только строка (как в innodb)?

Сделал еще пару тестов - PG немного "тупее" myisam на выборках (но результат выдает стабильнее), и намного привосходит innodb.

Спустя 16 минут, 10 секунд (10.11.2010 - 08:49) Семён написал(а):
Стесняюсь спросить, а ресурсы выделенные под MySQL и PostgreSQL были выделены одинаковые? Default настройки - тест ниочём. + операционная система одинаковая ?

Спустя 44 минуты, 51 секунда (10.11.2010 - 09:34) sergeiss написал(а):
Цитата (Семён @ 10.11.2010 - 09:49)
Default настройки - тест ниочём.

Большинство систем работают с дефолтными настройками, вобщем-то. Так что корректно это вполне.
Цитата (kirik @ 10.11.2010 - 09:33)
sergeiss, никак не могу найти информацию по поводу блокироки в PG..

У меня в подписи есть ссылка на хэлп. Рекомендую smile.gif
Сейчас глянул - можно и на таблицу, и на строку.

Цитата
13.3. Explicit Locking
PostgreSQL provides various lock modes to control concurrent access to data in tables. These modes can be used for application-controlled locking in situations where MVCC does not give the desired behavior. Also, most PostgreSQL commands automatically acquire locks of appropriate modes to ensure that referenced tables are not dropped or modified in incompatible ways while the command executes. (For example, ALTER TABLE cannot safely be executed concurrently with other operations on the same table, so it obtains an exclusive lock on the table to enforce that.)

To examine a list of the currently outstanding locks in a database server, use the pg_locks system view. For more information on monitoring the status of the lock manager subsystem, refer to Chapter 26, Monitoring Database Activity.

13.3.1. Table-Level Locks
......

13.3.2. Row-Level Locks
.......


Оттуда же:
Цитата
LOCK [ TABLE ] [ ONLY ] name [, ...] [ IN lockmode MODE ] [ NOWAIT ]

where lockmode is one of:

    ACCESS SHARE | ROW SHARE | ROW EXCLUSIVE | SHARE UPDATE EXCLUSIVE
    | SHARE | SHARE ROW EXCLUSIVE | EXCLUSIVE | ACCESS EXCLUSIVE

Спустя 1 минута, 1 секунда (10.11.2010 - 09:35) Joker написал(а):
Семён
у меня запросы покруче))) я ими убил оракл)))) и плюс взорвал мозг штатному бдшнику)))



Спустя 2 минуты, 21 секунда Joker написал(а):
у нас тестировали мускул и постгре, в итоге было выбрана постгре, тестировалась на отказа устойчивость, скорость выполнения, и функциональность. результаты тестирования врятли покажу т.к. другой отдел этим занимается но если их заполучу опубликую)

Спустя 8 минут, 29 секунд (10.11.2010 - 09:43) Семён написал(а):
На сколько мне известно тажа к примеру задействованная память у MySQL и PostgreSQL в дефаулт настройках разная. Последние события кстати с кастрацией mySQL меня стали разочаровывать.

Спустя 44 минуты, 34 секунды (10.11.2010 - 10:28) Семён написал(а):
Kirik, я вот кстати ещё подумал
Вот рассмотрим запрос вида:
SELECT *
FROM links_posts AS p
ORDER BY p.post_id DESC
LIMIT 11 OFFSET 333


Данный запрос с ограничением больше подходит к PostgreSQL, чем к MySQL, попробуй этот же запрос без OFFSET-a, но указав явно LIMIT x,y

Спустя 1 минута, 37 секунд (10.11.2010 - 10:29) kirik написал(а):
Цитата (Семён @ 10.11.2010 - 00:49)
Стесняюсь спросить, а ресурсы выделенные под MySQL и PostgreSQL были выделены одинаковые?

Ресурсы-то одни, вот с настройками я в PG не разбирался еще, mysql'ных аналогов не знаю по этому. Если что вот все переменные mysql и pgsql c которыми я тестил.

Цитата (Семён @ 10.11.2010 - 00:49)
операционная система одинаковая ?

Да, на одной машине все тестировал.

Цитата (sergeiss @ 10.11.2010 - 01:34)
У меня в подписи есть ссылка на хэлп. Рекомендую

Динькуе! smile.gif Кстате mysql'ный мануал мне был понятнее smile.gif

Цитата (Joker @ 10.11.2010 - 01:35)
результаты тестирования врятли покажу т.к. другой отдел этим занимается но если их заполучу опубликую

Было бы круто!

Цитата (Семён @ 10.11.2010 - 01:43)
На сколько мне известно тажа к примеру задействованная память у MySQL и PostgreSQL в дефаулт настройках разная.

Наверняка smile.gif Подкупает строчка в мануале к PG: "с настройками по умолчанию PG ориентирован на стабильную работу на любой системе, а не на скорость" smile.gif

Цитата (Семён @ 10.11.2010 - 01:43)
Последние события кстати с кастрацией mySQL меня стали разочаровывать.

Ага smile.gif Это служит мотиватором к поиску других БД smile.gif

Спустя 40 секунд (10.11.2010 - 10:30) kirik написал(а):
Цитата (Семён @ 10.11.2010 - 02:28)
попробуй этот же запрос без OFFSET-a, но указав явно LIMIT x,y

Разве не одно и тоже? Ща попробую..

Спустя 6 минут, 41 секунда (10.11.2010 - 10:37) Семён написал(а):
Цитата (kirik @ 10.11.2010 - 11:30)
Цитата (Семён @ 10.11.2010 - 02:28)
попробуй этот же запрос без OFFSET-a, но указав явно LIMIT x,y

Разве не одно и тоже? Ща попробую..

Результат будет один и тот же, а вот скорость разная, т.к. в родном диалекте OFFSET идёт через LIMIT x,y, в PostgreSQL через OFFSET, в FireBird FIRST a SKIP b

Спустя 5 минут, 9 секунд (10.11.2010 - 10:42) kirik написал(а):
Семён, не, схожие результаты получились.

Спустя 23 секунды (10.11.2010 - 10:42) Семён написал(а):
Да и кстати я проводил тесты MySQL на больших таблицах, Glock мне в своё время очень помог с объяснением тех или иных моментов в SQL. Выборка из таблички в 750 000 записей проходила менее чем за 0.2с. при условии того, что запрос был гораздо сложнее, а всего-то индексы правильно расставили и типы данных. Kir, я даже и не знаю, что можно предложить, но на таких запросах MySQL должна шустрее делать выборки имхо, в то время как PostgreSQL сделает по скорости на более сложных с JOIN-ами тежами.

Спустя 18 минут, 11 секунд (10.11.2010 - 11:00) kirik написал(а):
Семён, мы с товарищем Васей в свое время разбирали мой случай - максимум чего добились, то тупит. Выборка по индексам - да, моментальная, но Mysql именно на больших оффсетах заваливается. Если у тебя остался тот большой дамп, можешь потестить у себя.

Спустя 1 минута, 12 секунд (10.11.2010 - 11:02) Семён написал(а):
kirik, на больших OFFSET-ах согласен

Спустя 5 минут, 41 секунда (10.11.2010 - 11:07) Семён написал(а):
Только вот к примеру решение этого вопроса, только есть естественно некоторые нюансы ))

SELECT * FROM `myBigTable` WHERE `id` > :OFFSET LIMIT :BATCH_SIZE;
SELECT * FROM `myBigTable` WHERE `id` > :OFFSET ORDER BY `id` ASC;


Нужно только индексы не забыть :D

Спустя 12 минут, 9 секунд (10.11.2010 - 11:20) kirik написал(а):
Цитата (sergeiss @ 10.11.2010 - 01:34)
Сейчас глянул - можно и на таблицу, и на строку.

Почитал:
Цитата (http://www.postgresql.org/docs/8.2/interactive/explicit-locking.html)
An exclusive row-level lock on a specific row is automatically acquired when the row is updated or deleted. ....  Row-level locks do not affect data querying; they block writers to the same row only.

По-русски: при update или delete лочится только обновляемая/удаляемая строка, причем блокируется только на запись.

Спустя 9 минут, 7 секунд (10.11.2010 - 11:29) kirik написал(а):
Семён
Хе) у меня сейчас похожее решение: постраничный вывод только кнопкаи "вперед" и "назад" и сортировка только по дате - отрубил из-за тупок полгода назад. Убивает напрочь возможность сортировки по другим полям (с id и датой ужасный костыль получился).

Спустя 4 минуты, 34 секунды (10.11.2010 - 11:33) Семён написал(а):
Ну, а так вообще таким способом выборка происходит мгновенно smile.gif

Спустя 2 минуты, 6 секунд (10.11.2010 - 11:35) Семён написал(а):
Цитата (kirik @ 10.11.2010 - 12:29)
Семён
Хе) у меня сейчас похожее решение: постраничный вывод только кнопкаи "вперед" и "назад" и сортировка только по дате - отрубил из-за тупок полгода назад. Убивает напрочь возможность сортировки по другим полям (с id и датой ужасный костыль получился).

А кто мешает сделать 2-ве сортировки ?

Спустя 4 часа, 58 минут, 49 секунд (10.11.2010 - 16:34) sergeiss написал(а):
Насчет существенного ускорения выборки с оффсетами Валдиком как-то рассказывал. Простейшее, но очень эффективное решение.

Спустя 5 часов, 8 минут, 43 секунды (10.11.2010 - 21:43) kirik написал(а):
Цитата (Семён @ 10.11.2010 - 03:35)
А кто мешает сделать 2-ве сортировки ?


Тут ответ на твой вопрос :)

Возьмем табличку:
id | title | date
-----------------
1 | c | 12
2 | e | 13
3 | a | 10
4 | b | 14
5 | e | 11


Выводим нашим способом вторую страницу с сортировкой по id:
SELECT * FROM table
WHERE
id > 2
ORDER BY id ASC
LIMIT
2



id | title | date
-----------------
1 | c | 12
2 | e | 13

3 | a | 10
4 | b | 14
5 | e | 11


Теперь выводим вторую страницу отсортированную по date
SELECT * FROM table
WHERE
date > 11
ORDER BY date ASC
LIMIT
2

id | title | date
-----------------
3 | a | 10
5 | e | 11

1 | c | 12
2 | e | 13
4 | b | 14


Ну а теперь подумаем как вывести вторую страницу с сортировкой по date и title:

Получиться должно как-то так:
id | title | date
-----------------
3 | a | 10
5 | e | 11

2 | e | 13
1 | c | 12
4 | b | 14


Сделать можно, но костыль получается очень некрасивый :)

Спустя 1 час, 40 минут, 9 секунд (10.11.2010 - 23:23) Семён написал(а):
ыыыыыыыыы
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.