Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
 MySQL vs. PostgreSQL holy war  [new]
tyler19
Member

Откуда:
Сообщений: 1
Часто возникают споры какая из DBMS лучше. Однако обе они работают достаточно быстро с малыми объёмами данных. Тестирование с большими объёмами данных затруднительно т.к. приходится искусственно создавать данные.

Предлагаю сторонникам одной из этим DBMS посоветовать оптимизации которые только можно применить к этой таблице. Таким образом вы мне очень поможете и будет видно какая DBMS всё таки лучше для больших объёмов данных.

Выслушаю также предложения по другим DBMS в том числе NoSQL.

Имеется таблица

в MySQL:

CREATE TABLE `videos` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `site` varchar(255) NOT NULL,
  `site_id` bigint(20) unsigned NOT NULL,
  `site_url` varchar(255) NOT NULL,
  `title` text NOT NULL,
  `thumbnails` text NOT NULL,
  `duration_txt` varchar(32) NOT NULL,
  `duration` bigint(20) unsigned NOT NULL,
  `embed` text NOT NULL,
  `created_on` datetime NOT NULL,
  `status` enum('active','deleted') NOT NULL DEFAULT 'active',
  `views` bigint(20) unsigned NOT NULL DEFAULT '0',
  `rating` bigint(20) unsigned NOT NULL DEFAULT '0',
  `voted` bigint(20) unsigned NOT NULL DEFAULT '0',
  PRIMARY KEY (`id`),
  KEY `site` (`site`),
  KEY `site_id` (`site_id`),
  KEY `site_url` (`site_url`),
  KEY `status` (`status`),
  KEY `created_on_id` (`created_on`,`id`)
) ENGINE=MyISAM AUTO_INCREMENT=1797645 DEFAULT CHARSET=utf8 ROW_FORMAT=FIXED


в PostgreSQL:

                                      Table "public.videos"
    Column    |            Type             |                      Modifiers                      
--------------+-----------------------------+-----------------------------------------------------
 id           | bigint                      | not null default nextval('videos_id_seq'::regclass)
 site         | character varying           | not null
 site_id      | bigint                      | not null
 site_url     | character varying           | not null
 title        | character varying           | not null
 thumbnails   | character varying           | not null
 duration_txt | character varying           | not null
 duration     | bigint                      | not null
 embed        | character varying           | not null
 created_on   | timestamp without time zone | not null
 views        | bigint                      | not null
 rating       | bigint                      | not null
 voted        | bigint                      | not null
 status       | status                      | not null default 'active'::status
Indexes:
    "videos_pkey" PRIMARY KEY, btree (id)
    "videos_created_on" btree (created_on)
    "videos_created_on_id" btree (created_on DESC, id DESC)


Задача как можно лучше оптимизировать запрос "SELECT * FROM videos WHERE status = 'active' ORDER BY created_on DESC, id DESC OFFSET 1050050 LIMIT 30". (OFFSET должен быть большим, таблица содержит 1,782,614 записей. Если это сильно увеличит производительность WHERE status = 'active' можно выкинуть и сделать хотя бы без него.
17 апр 13, 21:43    [14195317]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs. PostgreSQL holy war  [new]
Сергей Васкецов
Member

Откуда:
Сообщений: 20362
tyler19
Тестирование с большими объёмами данных затруднительно т.к. приходится искусственно создавать данные

И что тут затруднительного?
17 апр 13, 22:05    [14195403]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs. PostgreSQL holy war  [new]
Dimitry Sibiryakov
Member

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

tyler19
OFFSET 1050050 LIMIT 30

Против маразма медицина бессильна.

Posted via ActualForum NNTP Server 1.5

17 апр 13, 22:09    [14195426]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs. PostgreSQL holy war  [new]
V&N
Guest
tyler19, в postgresql, для навигации по большому набору данных можно использовать CURSOR

DECLARE cr_videos SCROLL CURSOR WITH HOLD FOR SELECT * FROM videos ORDER BY ....;

FETCH ABSOLUTE 100500 FROM cr_videos; --позиционирование на 100500 запись;
FETCH FORWARD 30 FROM cr_videos; --получить следующие 30 записей, с 100501 по 100530;

CLOSE cr_videos; --курсор не нужен;

или используйте дополнительное условие WHERE created_on >= ? AND id >= ? .... LIMIT 30 --(without offset)
или дополнительное пронумерованное+индексированное поле для условия + LIMIT.
18 апр 13, 13:54    [14198421]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs. PostgreSQL holy war  [new]
ScareCrow
Member

Откуда: Белый город
Сообщений: 17472
автор
ENGINE=MyISAM

мьсе знает толк в извращениях
18 апр 13, 16:13    [14199412]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs. PostgreSQL holy war  [new]
ScareCrow
Member

Откуда: Белый город
Сообщений: 17472
SELECT * FROM large WHERE id >  10000 ORDER BY id LIMIT 30 
18 апр 13, 16:15    [14199425]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs. PostgreSQL holy war  [new]
miksoft
Member

Откуда:
Сообщений: 38919
Для начала - эти таблиц неэквивалентны с точки зрения физического хранения. В MySQL поля типа text хранятся за пределами основных данных таблицы.
ROW_FORMAT=FIXED тоже вызывает сомнения при наличии полей типа varchar.

В данном случае я бы предложил индекс (status, created_on, id), возможно, с указанием DESC для последних двух полей.
18 апр 13, 16:27    [14199511]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs. PostgreSQL holy war  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3795
miksoft
Для начала - эти таблиц неэквивалентны с точки зрения физического хранения. В MySQL поля типа text хранятся за пределами основных данных таблицы.
ROW_FORMAT=FIXED тоже вызывает сомнения при наличии полей типа varchar.

В данном случае я бы предложил индекс (status, created_on, id), возможно, с указанием DESC для последних двух полей.

+1 про тексты
18 апр 13, 18:25    [14200182]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs. PostgreSQL holy war  [new]
S.G.
Member

Откуда: cartoon network
Сообщений: 30611
tyler19
Часто возникают споры какая из DBMS лучше. Однако обе они работают достаточно быстро с малыми объёмами данных.
Поему, когда сравниваются две СУБД, почти всегда используется слово "быстро", и только оно?
18 апр 13, 20:59    [14200639]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs. PostgreSQL holy war  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
S.G.
tyler19
Часто возникают споры какая из DBMS лучше. Однако обе они работают достаточно быстро с малыми объёмами данных.
Поему, когда сравниваются две СУБД, почти всегда используется слово "быстро", и только оно?
Потому что сравнивают разработчики ;)
19 апр 13, 00:49    [14201177]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs. PostgreSQL holy war  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3795
S.G.
tyler19
Часто возникают споры какая из DBMS лучше. Однако обе они работают достаточно быстро с малыми объёмами данных.
Поему, когда сравниваются две СУБД, почти всегда используется слово "быстро", и только оно?

Начнем с того что у "быстро" 100500 подвидов...
Ну а цена учитывается еще до того как начинается сравнение... то-то у ТС две бесплатные субд в листе
:)
19 апр 13, 14:27    [14204030]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs. PostgreSQL holy war  [new]
Arhat109
Member

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

поддержу. Более того, вариант на Мускуле почему-то "внезапно" имеет индекс на status, а в Постгресе - "нафиг"... хотя его селективность может оказаться никакущей...

... у меня есть "похожая" табличка ... пишет лог статистики запросов в БД. Выборка отдает среднее время страницы за менее чем 100мсек. При объеме таблицы в 2.5млн. записей.

и? Чего можно сравнивать на простых выборках... не понятно. Там "хоть какой объем"... по сути "возьми 30 записей отсюдова"... нашли блок, вытащили 30 записей из него... или нескольких блоков. Делов-то, для любой СУБД. А при нормально настроенном кеше - так ваще ниочемный вопрос.
19 апр 13, 20:38    [14206487]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs. PostgreSQL holy war  [new]
догадались
Guest
нутк

1. создайте в ПЖ условный индекс
CREATE INDEX "videos_created_on_id_active" ON  videos (created_on DESC, id DESC) WHERE  status = 'active' 


ну и
2. при массированном запрашиваниии "отстраничивания с глубоким позиционированием" (offset 1005001000000) постройте ,что-ли, материализованные соответствия row_num<->id, если конечно число разнобразных разрезов ( в данном случае это ("created_on DESC, id DESC) WHERE status = 'active'") , вдоль которого [идиотской приладе] требуется этот идиотизм не слишком велико


3. осмелюсь заметить, что , id DESC как в условии, так и в индесках не только лишнее, но и проявляет нам во всей , такскаать, полноте, ага (ну вы догадались)
1 май 13, 15:58    [14252625]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs. PostgreSQL holy war  [new]
догадались
Guest
догадались,
с 3 наврал таки, но не суть
1 май 13, 16:04    [14252636]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs. PostgreSQL holy war  [new]
Warstone
Member

Откуда:
Сообщений: 4896
Блог
Если вы хотите адекватные условия, то воткните у MySQL ENGINE - InnoDB. Иначе это не смешно. Или для ПГ используйте UNLOGGED таблицы (только помните что они очищаются при рестарте СУБД).
15 май 13, 22:32    [14302278]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs. PostgreSQL holy war  [new]
Misha Tyurin
Member

Откуда: Тюмень
Сообщений: 2243
автор
только помните что они очищаются при рестарте СУБД


!!! очищаются только при аварийном "выключение". если штатно тушите - всё ok сохраняется.

но они не реплицируются - это да
21 май 13, 17:52    [14328937]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs. PostgreSQL holy war  [new]
Warstone
Member

Откуда:
Сообщений: 4896
Блог
Misha Tyurin
автор
только помните что они очищаются при рестарте СУБД


!!! очищаются только при аварийном "выключение". если штатно тушите - всё ok сохраняется.

но они не реплицируются - это да
Гм... сейчас перечитал доку... Да... Вы правы, но все-равно - считаем что при рестарте данных в таблице нету.
25 май 13, 03:02    [14348521]     Ответить | Цитировать Сообщить модератору
Все форумы / Сравнение СУБД Ответить