Тема: PostgreSQL • MySQL • SQLite що швидше?
Чи проводив хтось тести яка база ( PostgreSQL • MySQL • SQLite) краще проявляє себе при навантаженнях?
Ви не увійшли. Будь ласка, увійдіть або зареєструйтесь.
Ласкаво просимо вас на україномовний форум з програмування, веб-дизайну, SEO та всього пов'язаного з інтернетом та комп'ютерами.
Будемо вдячні, якщо ви поділитись посиланням на Replace.org.ua на інших ресурсах.
Для того щоб створювати теми та надсилати повідомлення вам потрібно Зареєструватись.
Український форум програмістів → Бази даних → PostgreSQL • MySQL • SQLite що швидше?
Для відправлення відповіді ви повинні увійти або зареєструватися
Чи проводив хтось тести яка база ( PostgreSQL • MySQL • SQLite) краще проявляє себе при навантаженнях?
краще ніхто, мені порадили так, перестати слухати шо поставив і швидше працює, все через певний проміжок роботи буде тормозити.
Чи проводив хтось тести яка база ( PostgreSQL • MySQL • SQLite) краще проявляє себе при навантаженнях?
І можливо навіть був фанат котрий провів таке ж дослідження в зв"язці із Django! Як раз цікавить таке питання яка з баз буде кращою(оптимальнішою) для створення магазу на Django!
Djalin написав:Чи проводив хтось тести яка база ( PostgreSQL • MySQL • SQLite) краще проявляє себе при навантаженнях?
І можливо навіть був фанат котрий провів таке ж дослідження в зв"язці із Django! Як раз цікавить таке питання яка з баз буде кращою(оптимальнішою) для створення магазу на Django!
Будь-яка.
При, перепрошую, яких навантаженнях?
Не знаю, як зараз, але традиційне позиціонування було таке: SQLite - вбудована БД для однієї програми, MySQL - окремо працює на тому ж чи суміжному сервері, PostgreSQL - розподілена по кількох серверах система. А навантаження - вони різні бувають.
А ще є NoSQL, якісь штуки повязані з Hаdoop, так шо треба просто дійсно розібратися які навантаження, які операції будуть найчастіше виконуватися, який обсяг даних зберігатиметься...
Перепрошую, що відповідаю за пана, але як вже ж у курсі...
Питання виникло у контексті розробки системи обліку переглядів (припустимо, лічильник відвідин як таких), тому:
- обсяг збереження інформації мінімальний
- характер навантаження - постійне оновлення окремих значень
Окремо відзначу що традиційне позиціонування зараз не має надто суттєвої ролі - як PostgreSQL, так і MySQL чудово кластеризуються.
Справа в тому, що навіть якщо взяти одну лише MySQL, то вона має різні рушії таблиць (InnoDB, MyISAM, Memory...), які заточені під конкретні потреби (підтримка транзакцій, швидка вибірка...).
Тобто "навантаження" та навіть "постійне оновлення окремих значень" - це зовсім не однозначні поняття, і треба детально розписувати що саме вам потрібно.
ktretyak, уявіть сторінку, яка просто-напросто рахує усі її відкриття.. одне числове значення. Не дуже помилитесь.
ktretyak, уявіть сторінку, яка просто-напросто рахує усі її відкриття.. одне числове значення. Не дуже помилитесь.
Ок, якщо говорити лише про вставку значень, то SQLite з цим справляється найгірше.
ktretyak, от і я про те подумав, що врешті-решт роль embedded-сервера змушує його весь час синхронізувати вміст з фактичним сховищем-файлом, а отже це ані краплі не рятує в сенсі зменшення навантаження на гвинт порівняно із звичайним file_put_contents, скажімо
Само собою що жодного сенсу немає підбирати будь-яку БД, якщо вам потрібно лише одне число, яке тупо збільшує своє значення при кожному завантаженні сторінки.
Якщо ж вам треба хоча б бачити хто саме ходить по вашому сайті, яку поведінку має, скільки нових користувачів, а скільки постійних, то тоді вже й можна подивлятись в бік БД.
ktretyak, тобто, у вищенаведеному сценарії ви вважаєте file_put_contents або аналогічну операцію найоптимальнішою?
ktretyak, тобто, у вищенаведеному сценарії ви вважаєте file_put_contents або аналогічну операцію найоптимальнішою?
Однозначно.
ktretyak, щиро сподіваюсь що це був жарт, бо виконувати файлову операцію запису щовідвідин сторінки (яких може бути і чимало на секунду) - і поруч не лежить з оптимальністю...
ktretyak, щиро сподіваюсь що це був жарт, бо виконувати файлову операцію запису щовідвідин сторінки (яких може бути і чимало на секунду) - і поруч не лежить з оптимальністю...
Раз таке пишете, то мабуть ви зможете відповісти на запитання: "За який час відбувається операція вставки/оновлення при роботі функції file_put_contents()?"
ktretyak, ви натякаєте, що у кожній системі це фіксована абсолютна цифра? Бо інакше я не дуже вловлюю суті цього питання
ktretyak, ви натякаєте, що у кожній системі це фіксована абсолютна цифра? Бо інакше я не дуже вловлюю суті цього питання
Ви описуєте свою задачу
уявіть сторінку, яка просто-напросто рахує усі її відкриття.. одне числове значення
І при цьому хочете почути щось більш чітке, ніж "так це оптимально", чи "оце не можна, а оце спробуйте"?
Це не логічно. Хочете деталей, описуйте більш детально, бо може й справді у вас сотні тисяч конкуруючих запитів за секунду, а я тут вам раджу використовувати функцію file_put_contents().
ktretyak, проблема з самісінького початку поставлена як "що є найпродуктивнішим варіантом", тобто працює швидше (не з точки зору часу написання, тощо). Одне числове значення також може переписуватись дуже багато раз за одну секунду, так, тому питання швидкості й оптимальності навантаження для цієї задачі стоїть так само як і для будь-якої іншої - навіть при крихітному обсязі даних
Вибачте, але очевидно, що ви досить далекий від предмету спору, тому думаю я завершу на цьому.
P.S. Заради інтересу спробував зробити операції зчитування та оновлення 10 тис. разів на своєму компі ось цим скриптом:
<?php
$test_num = 10000;
$filename = 'test_insert.txt';
file_put_contents($filename, 0);
echo 'start: '.time().'<br>';
for($i = 0; $test_num > $i; $i++)
{
$num = file_get_contents($filename);
file_put_contents($filename, ++$num);
}
echo 'finish: '.time();
В мене відбувається таке оновлення за 5-6 секунд, тобто за секунду до 2 тис. разів.
Для відправлення відповіді ви повинні увійти або зареєструватися