GrAndSE's blog

Порівняння швидкодії БД (PostgreSQL, MySQL, SQLite)

Думаю, найбільш популярною на сьогодняшній день серед розробників є БД MySQL. Досить простий у використанні, розповсюджений серед хостерів, більшість CMS орієнтовані саме на нього, а починаючи з 5ої версії в цій системі з'явилось багато можливостей, притаманних корпоративним БД. І список можливостей продовжує рости. Розробники та прихильники MySQL досить часто стверджують, що він дуже швидкий, гнучкий та здатний до масштабування.

Однак, не дивлячись на те з MySQL все так добре та чудово, самеPostgreSQL використовується для збереження данних в більшості великих соціальних мереж, саме нею скористалось Yahoo! для побудови найбільшої в світі БД. Цікаво, що прихильники PostgreSQL з гордістю кажуть, що їх улюбленець значно швидший за MySQL, ну а його прихильники в свою чергу доволі часто кажуть протилежне.

А тут ще SQLite, що займає доволі потужні позиції в desktop-орієнтованому софті, а ще дехто каже про чудові можливості Firebird. І це тільки найпопулярніші з opensource баз данних.

Втомившись читати купу різних порівнянь, вирішив провести для себе самого ряд простих тестів та нашвидкоруч оцінити як поводять себе деякі БД.

GROUP_CONCAT та інші дрібнички в PostgreSQL

Не вперше я хочу написати про БД PostgreSQL. Цього разу хочу розповісти про декілька дрібничок, що можуть стати неприємною несподіванкою для людей, що довгий час працювали з MySQL та зіпсувати враження від цієї чудової БД. І ось такі дрібнички часто є причиною того, що PostgreSQL вважається деякими програмістами системою значно складнішою в роботі за MySQL. Особисто я з цим не можу погодитись - просто треба знати, як і що зробити саме тут.

Ну що ж. Розпочнемо з простого, а там буде видно.

MySQL proxy та логування запитів

Вже більше тижня я ніяк не можу одужати. Переважно лежу вдома, відпочиваю та набираюсь сил. Тому досить довгий час я не міг зібратись з думками та дописати (хоча й почав доволі давно) продовження своєї розповіді про молодий та цікавий проект MySQL proxy, що дозволяє досить легко проксювати запити до одного чи декількох серверів MySQL. Нагадаю, що таким чином можна створювати системи, що можуть витримувати підвищені навантаження, внаслідок розподілення запитів між декількома серверами, систему автоматичного коректування запитів, чи систему ведення логів запитів та підключень для декількох різних серверів. Думаю, що невеличке занурення в написання lua-скриптів для конфігурування MySQL proxy слід розпочати саме з такої досить простої задачі (це я про ведення логів).

Для початку рекомендую продивитись попередній матеріал та мою ж розповідь про Lua, хоча це й необов'язково.

Погляд на MySQL proxy

Останнім часом я аж дві статті присвятив СУБД PosgreSQL. Як Ви могли помітити, мені дуже подобається ця СУБД. Хоча й MySQL моєю увагою в щоденній роботі необділена. А ось інформацією про неї я не ділився. Просто нічого цікавого, про що б не написали на кожному кроці на думку не спадало. І ось я мені випала можливість познайомитись з не дуже освітленими аспектами роботи з MySQL, а саме побудовою систем проксювання запитів для MySQL та утилітою MySQL proxy.

Взагалі матеріалів з цього приводу доволі мало, не те що українською, а навіть і англійською мовою, тому з гордістю хочу розпочати написання невеличкої серії статей про те, як можна зменшити навантаження на СУБД MySQL, шляхом проксювання запитів через MySQL proxy.