Вам нужно почитать книги про архитектуру баз данных, нормальные формы и всё такое. Ваши тесты непоказательны - 10000 записей любая их этих баз не заметит.
По поводу почему отговаривали так делать... Обычно люди используют СУБД для работы с более сложными отношениями данных. Если вам нужно дать возможность нескольким людям соединяться с базой напрямую и хранить что-то в независимых табличках с 4-мя полями - почему нет? Главное прав им больше не давайте.
Но это странный бизнес-кейс какой-то. Обычно либо пользователи работают с базой через приложение (в этом случае на индексах экономить смысла нет и одной таблицей будет проще управлять, тем более, что 3000 пользователей * 10000 строк = 30,000,000 - это немного), либо это shared hosting и пользователям дают доступ к базе, а не одной табличке.
Черчение у нас было в 5м классе, но, к сожалению, учитель был не очень хороший. Он больше самоутверждался, чем учил. В вузе черчение было непрофильным на нашем факультете, преподавательница запомнилась тем, что критиковала меня за то, что не пыталась в вузе себе жениха найти. А вот с профильного факультета замена запомнилась, там прямо головоломки мы решали с преподавателем. Жалко, что недолго. Сам по себе предмет интересный.
Статья сплошной facepalm. MySQL без настроек заточен под очень слабую машину. Как минимум innodb_buffer_pool_size и innodb_log_file_size нужно поменять. Судя по тому, что автор пользуется хостингом, скорее всего, хостинг провайдер и настроил MySQL, а PostgreSQL нет :)
XtraDB это InnoDB с фичами Percona. Все bug fixes, new features портируются из InnoDB после каждого релиза. Там может что-то воспроизводиться, не воспроизводимое с MySQL, но это достаточно редкий случай. Скорее настройки надёжности отключены для большей производительности. innodb_double_write, innodb_flush_logs_at_trx_commit, вот это всё
Ну вот сейчас понятнее, спасибо! А то в начале получалось, что это мы с Настей вдвоём тестировали, а не статью писали. А суть проекта именно в том, что специалист по PostgreSQL тестирует PostgreSQL, специалист по MySQL тестирует MySQL.
Кстати good point. Их по факту 64, конечно. Вообще я не очень понимаю в каких случаях лучше меньше да лучше сейчас, на 5.7+. Конкретно в этом тесте я видела Buffer pool mutex contention при меньших значениях. Но было бы интересно попробовать с данными, где result set большой.
В принципе были планы к ним и перейти. Просто с чего-то начинать же нужно. В статье именно поэтому подробно описываются трудности, с которыми мы столкнулись
2% — это погрешность всё-таки. Насчёт патча — это конкретный ворклод. Наверняка и для MySQL можно найти такой даже сейчас, что только патчить. PS — у да, там и ворклод, и скорость диска имеют значение.
Пропустили. Я перевод не вычитывала. В оригинале где я про более слабую машину говорю — это тест MySQL- я. А результаты PostgreSQL и MySQL сравнивались на идентичных машинах. (На которых 144 ядра)
Ну и, кстати, я видела очень крутые исследования сейлзов (продавцов), которые потом тру девелоперы в своих презентациях показывали. Так что не вижу ничего плохого или странного в том, что специалист по маркетингу что-то тестирует. Хоть в данном случае у Насти была другая роль.
Сорри, планшет отправил комментарий неоконченный. Это перевод статьи из блога компании где я работаю. Вот оригинал: https://www.percona.com/blog/2017/01/06/millions-queries-per-second-postgresql-and-mysql-peaceful-battle-at-modern-demanding-workloads/ Настя там в роли ведущего, она ничего не тестировали. Тестировала я и Александр Коротков из PostgreSQL Professional. То есть идея была в том, что специалист по PostgreSQL и MySQL совместно работают на одинаковом железе. Чтобы не было такого: «Света взяла постгрес из коробки и у неё он какой-то тормозной» и аналогично с другой стороны.
Ребят, вы, конечно, молодцы. Но где указание, что это перевод? Где ссылка на блог компании Percona, где пост был изначально опубликован? Где прямое явное указание в начале текста на то, что PostgreSQL тестировали специалисты именно по нему, а именно компания PostgreSQL Professional?
Вам нужно почитать книги про архитектуру баз данных, нормальные формы и всё такое. Ваши тесты непоказательны - 10000 записей любая их этих баз не заметит.
По поводу почему отговаривали так делать... Обычно люди используют СУБД для работы с более сложными отношениями данных. Если вам нужно дать возможность нескольким людям соединяться с базой напрямую и хранить что-то в независимых табличках с 4-мя полями - почему нет? Главное прав им больше не давайте.
Но это странный бизнес-кейс какой-то. Обычно либо пользователи работают с базой через приложение (в этом случае на индексах экономить смысла нет и одной таблицей будет проще управлять, тем более, что 3000 пользователей * 10000 строк = 30,000,000 - это немного), либо это shared hosting и пользователям дают доступ к базе, а не одной табличке.
Черчение у нас было в 5м классе, но, к сожалению, учитель был не очень хороший. Он больше самоутверждался, чем учил. В вузе черчение было непрофильным на нашем факультете, преподавательница запомнилась тем, что критиковала меня за то, что не пыталась в вузе себе жениха найти. А вот с профильного факультета замена запомнилась, там прямо головоломки мы решали с преподавателем. Жалко, что недолго. Сам по себе предмет интересный.
Вообще странно, что с innodb_doublewrite и innodb_flush_log_at_trx_commit=1 у вас такое регулярно происходит.
Впрочем вот это объясняет:
Для 1-2 гигабайт нечасто обновляемых данных можно и с настройками по умолчанию жить.