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. Особисто я з цим не можу погодитись - просто треба знати, як і що зробити саме тут.

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

Оптимізація запитів для повнотекстового пошуку в PostgreSQL

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

А сьогодні я хочу на прикладі розповісти про деякі тонкощі написання запитів для роботи з повнотекстовим пошуком.

Повнотекстовий пошук в PostgreSQL

На багатьох інформаційних інтернет ресурсах дуже часто можна побачити форму для пошуку сайтом. В більшості випадків такі системи пошуку є дуже обмеженими. Обмеженими в силу тих інструментів, які для його організації використовуються. Я кажу про СУБД MySQL та запити типу "like". Такий підхід дозволяє за пошуковим запитом сформувати шаблон, і кожен запит в БД перевіряється на відповідність цьому шаблону. Недоліками такого підходу є швибкодія, відсутність можливостей для ранжування результатів пошукового запиту, проблеми з гнучкістю побудови запитів та ігнорування правил морфології. Наприклад, за словом "стаття" як результат повернено буде лише матеріали, що включають це слово повністю і в тому вигляді, в якому воно й було введено.

Звичайно можна вигадувати обхідні шляхи для подолання таких проблем "like-пошуку". Наприклад, обробляти рядок пошуку якимось алгоритмом стемінгу з метою виділення можливих коренів слів і використовувати для пошуку ці корені. А щоб пошукати за декількома словами додамо до пошукового запиту для кожного додаткового слова "AND like" і т.д.

Однак це не вихід.