|
MySQL vs. PostgreSQL holy war
|
|||
---|---|---|---|
#18+
Часто возникают споры какая из DBMS лучше. Однако обе они работают достаточно быстро с малыми объёмами данных. Тестирование с большими объёмами данных затруднительно т.к. приходится искусственно создавать данные. Предлагаю сторонникам одной из этим DBMS посоветовать оптимизации которые только можно применить к этой таблице. Таким образом вы мне очень поможете и будет видно какая DBMS всё таки лучше для больших объёмов данных. Выслушаю также предложения по другим DBMS в том числе NoSQL. Имеется таблица в MySQL: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22.
в PostgreSQL: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21.
Задача как можно лучше оптимизировать запрос "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.04.2013, 21:43 |
|
MySQL vs. PostgreSQL holy war
|
|||
---|---|---|---|
#18+
tyler19Тестирование с большими объёмами данных затруднительно т.к. приходится искусственно создавать данные И что тут затруднительного? ... |
|||
:
Нравится:
Не нравится:
|
|||
17.04.2013, 22:05 |
|
MySQL vs. PostgreSQL holy war
|
|||
---|---|---|---|
#18+
tyler19OFFSET 1050050 LIMIT 30 Против маразма медицина бессильна. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
17.04.2013, 22:09 |
|
MySQL vs. PostgreSQL holy war
|
|||
---|---|---|---|
#18+
tyler19, в postgresql, для навигации по большому набору данных можно использовать CURSOR Код: plsql 1. 2. 3. 4. 5. 6.
или используйте дополнительное условие WHERE created_on >= ? AND id >= ? .... LIMIT 30 --(without offset) или дополнительное пронумерованное+индексированное поле для условия + LIMIT. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2013, 13:54 |
|
MySQL vs. PostgreSQL holy war
|
|||
---|---|---|---|
#18+
авторENGINE=MyISAM мьсе знает толк в извращениях ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2013, 16:13 |
|
MySQL vs. PostgreSQL holy war
|
|||
---|---|---|---|
#18+
Код: sql 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2013, 16:15 |
|
MySQL vs. PostgreSQL holy war
|
|||
---|---|---|---|
#18+
Для начала - эти таблиц неэквивалентны с точки зрения физического хранения. В MySQL поля типа text хранятся за пределами основных данных таблицы. ROW_FORMAT=FIXED тоже вызывает сомнения при наличии полей типа varchar. В данном случае я бы предложил индекс (status, created_on, id), возможно, с указанием DESC для последних двух полей. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2013, 16:27 |
|
MySQL vs. PostgreSQL holy war
|
|||
---|---|---|---|
#18+
miksoftДля начала - эти таблиц неэквивалентны с точки зрения физического хранения. В MySQL поля типа text хранятся за пределами основных данных таблицы. ROW_FORMAT=FIXED тоже вызывает сомнения при наличии полей типа varchar. В данном случае я бы предложил индекс (status, created_on, id), возможно, с указанием DESC для последних двух полей. +1 про тексты ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2013, 18:25 |
|
MySQL vs. PostgreSQL holy war
|
|||
---|---|---|---|
#18+
tyler19Часто возникают споры какая из DBMS лучше. Однако обе они работают достаточно быстро с малыми объёмами данных. Поему, когда сравниваются две СУБД, почти всегда используется слово "быстро", и только оно? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2013, 20:59 |
|
MySQL vs. PostgreSQL holy war
|
|||
---|---|---|---|
#18+
S.G.tyler19Часто возникают споры какая из DBMS лучше. Однако обе они работают достаточно быстро с малыми объёмами данных. Поему, когда сравниваются две СУБД, почти всегда используется слово "быстро", и только оно?Потому что сравнивают разработчики ;) ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2013, 00:49 |
|
MySQL vs. PostgreSQL holy war
|
|||
---|---|---|---|
#18+
S.G.tyler19Часто возникают споры какая из DBMS лучше. Однако обе они работают достаточно быстро с малыми объёмами данных. Поему, когда сравниваются две СУБД, почти всегда используется слово "быстро", и только оно? Начнем с того что у "быстро" 100500 подвидов... Ну а цена учитывается еще до того как начинается сравнение... то-то у ТС две бесплатные субд в листе :) ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2013, 14:27 |
|
MySQL vs. PostgreSQL holy war
|
|||
---|---|---|---|
#18+
miksoft, поддержу. Более того, вариант на Мускуле почему-то "внезапно" имеет индекс на status, а в Постгресе - "нафиг"... хотя его селективность может оказаться никакущей... ... у меня есть "похожая" табличка ... пишет лог статистики запросов в БД. Выборка отдает среднее время страницы за менее чем 100мсек. При объеме таблицы в 2.5млн. записей. и? Чего можно сравнивать на простых выборках... не понятно. Там "хоть какой объем"... по сути "возьми 30 записей отсюдова"... нашли блок, вытащили 30 записей из него... или нескольких блоков. Делов-то, для любой СУБД. А при нормально настроенном кеше - так ваще ниочемный вопрос. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2013, 20:38 |
|
MySQL vs. PostgreSQL holy war
|
|||
---|---|---|---|
#18+
нутк 1. создайте в ПЖ условный индекс Код: plsql 1.
ну и 2. при массированном запрашиваниии "отстраничивания с глубоким позиционированием" (offset 1005001000000) постройте ,что-ли, материализованные соответствия row_num<->id, если конечно число разнобразных разрезов ( в данном случае это ("created_on DESC, id DESC) WHERE status = 'active'") , вдоль которого [идиотской приладе] требуется этот идиотизм не слишком велико 3. осмелюсь заметить, что , id DESC как в условии, так и в индесках не только лишнее, но и проявляет нам во всей , такскаать, полноте, ага (ну вы догадались) ... |
|||
:
Нравится:
Не нравится:
|
|||
01.05.2013, 15:58 |
|
MySQL vs. PostgreSQL holy war
|
|||
---|---|---|---|
#18+
догадались, с 3 наврал таки, но не суть ... |
|||
:
Нравится:
Не нравится:
|
|||
01.05.2013, 16:04 |
|
MySQL vs. PostgreSQL holy war
|
|||
---|---|---|---|
#18+
Если вы хотите адекватные условия, то воткните у MySQL ENGINE - InnoDB. Иначе это не смешно. Или для ПГ используйте UNLOGGED таблицы (только помните что они очищаются при рестарте СУБД). ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2013, 22:32 |
|
MySQL vs. PostgreSQL holy war
|
|||
---|---|---|---|
#18+
автортолько помните что они очищаются при рестарте СУБД !!! очищаются только при аварийном "выключение". если штатно тушите - всё ok сохраняется. но они не реплицируются - это да ... |
|||
:
Нравится:
Не нравится:
|
|||
21.05.2013, 17:52 |
|
MySQL vs. PostgreSQL holy war
|
|||
---|---|---|---|
#18+
Misha Tyurinавтортолько помните что они очищаются при рестарте СУБД !!! очищаются только при аварийном "выключение". если штатно тушите - всё ok сохраняется. но они не реплицируются - это даГм... сейчас перечитал доку... Да... Вы правы, но все-равно - считаем что при рестарте данных в таблице нету. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.05.2013, 03:02 |
|
|
start [/forum/topic.php?fid=35&msg=38246121&tid=1552458]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
39ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
50ms |
get tp. blocked users: |
1ms |
others: | 15ms |
total: | 145ms |
0 / 0 |