Часто возникают споры какая из 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' можно выкинуть и сделать хотя бы без него.