о сравнении SQLite и PostgreSQL Не морочьте людям голову. Велосипед полезен в одних случаях а камаз в других. и они не взаимозаменяемы.
Сравнение версионной и блокировочной СУБД вообще не корректно!!! Вы чтото писали про нагрузку на http сервер в 7000 запрсов в секунду. Так вот серьезная нагрузка это следующее: у вас есть 7000 клиентов постоянно подключенных к серверу. Каждый из них постоянно чтото читает/пишит а в это время вам нужно провести транзакцию длительностью ну к примеру в 15 минут(люди подтвердят что это нормально(и даже мало) для реальных систем). Такая транзакция затрагивает ну к примеру 1000 таблиц. Причем с первого прохода она не отрабатывает и на 10-й минуте происходит rollback и вам приходится стартовать транзакцию заново. И так весь день. Это ШТАТНАЯ СИТУАЦИЯ!!! В версионной СУБД пока вы целый день маетесь с одной транзакцией 7000 человек ничего не замечают. В СУБД с блокировками в описанной вами ситуации вы практически лишите возможности работать 7000 человек!!! Ведь все блокировано пока работает транзакция. Ваше начальство узнает о том что вы напрасно потратили 7000 человеко-дней за которое начальство платило денежку этим 7000 чел. В результате начальство умиляется от производительности SQLite и дарит вам букет цветов. Если у велосипеда сверх прочная и сверхлёгкая алюминиевая рама и надёжнейшие дисковые тормоза. Если в специально созданных для теста условиях велотрека ваш велосипед обгоняет камаз.... Это еще не повод объявлять что велосипед заменит камаз во всём. Посмотрю я на велосипед если на него нагрузят 20Т контейнер и поставят задачу за день перевезти с Киева в Одессу(500км). Люди я знаю что камазы плохи тем что 1) жрут много топлива 2) гремят 3) требуют специального обучения 4) дороги в ремонте и обслуживании 5) загрязняют окружающую среду 6) дороги но их НЕ ВСЕГДА можно заменить велосипедом!!! И оторванные тесты по скорости на велотреке или по потреблению топлива просто безумны. Это я про ссылки : "Тестирование PostgreSQL 8.3 на больших таблицах: 40М записей и ограничение ОЗУ" и тд Поймите: Это именно случай сравнивание камаза с велосипедом на велотреке. В Суб, 23/01/2010 в 11:35 +0300, Alexey Pechnikov пишет: > Hello! > > On Saturday 23 January 2010 00:22:04 Aleksey Cheusov wrote: > > > Какая гибкость - вы знаете другую SQL СУБД, способную выполнить миллион > > > селектов в минуту? > > Да я просто мимо прохожу на самом деле. Да и насчет миллионов селектов в > > минуту -- это эээ, в общем случае художественный вымысел, скажем так. > > В одном из проектов у меня это используется для быстрой обработки пакетных > данных. > > > > Обертки не поддерживают особенностей каждой СУБД, > > > ради которых и стоит ее выбирать. > > Вот именно. А если нам понадобиться расширяться вглудь и вширь. Очень > > значительно и быстро? И понадобятся возможности, отсутствующие в sqlite? > > Переписывать приложение опять на рога-и-копыта-дб? > > Детские страшилки. Вы используете дебиан - а что, если нам понадобятся > прямо через минуту воспользоваться отсутствующими функциями? Менять > систему на рога-и-копыта-ОС? Не скрою, некоторое здравое зерно в ваших > рассуждениях есть, потому я и поддерживаю свой репозиторий расширений > для эскулайт - во-первых, там реализовано то, что может в ближайших год > мне понадобиться (а может и не понадобиться), во-вторых, написав десяток > различных расширений, мне несложно написать и одиннадцатое, если в том > возникнет необходимость. И это расширение будет работать гарантированно > быстро и решать именно ту задачу, которую нужно решать. Плюс к тому > мы получаем систему, не требующую администрирования, в отличии от > клиент-серверных универсальных монстров. > И более того - навороченные возможности универсальных СУБД есть не более > чем маркетинг. Возиможности есть, но зачастую они оказываются бесполезны. > Как пример, тот же постгрес - умеет использовать функциональные индексы, > но запросы с ними работают настолько медленнее обыкновенных, что все > равно приходится добавлять поля в таблицы и триггерами их заполнять при > вставке/изменении. То есть делать ровно то же, что и в эскулайте. > > Все это я проверял тестами, в частности, см. > http://geomapx.blogspot.com/search/label/PostgreSQL > Особенно см. вот этот практический эскперимент: > http://geomapx.blogspot.com/2009/11/postgresql-81-vs-sqlite-3620-in-real.html > Как видим, оптимизированный _для постгреса_ запрос в эскулайте на тех же > данных работает на порядки быстрее. Про оптимизированный _для эскулайт_ > вариант запроса я даже писать не стал, и так все ясно. > > Есть и проблемы: > http://geomapx.blogspot.com/2009/11/degradation-of-indexing-speed.html > По идее, это нужно решать на уровне "движка", но такой путь потребует > изменения файлового формата, а это чревато. Потому пока вот такое > обходное решение (индекс по хэшу меньше настолько, насколько хеш > меньше, чем суммарный размер хэшируемых полей): > http://geomapx.blogspot.com/2009/12/murmurhash-20.html > > > > И таки да, на определенных задачах > > > быстродействие врапперов неприемлемо. > > Я просил конкретные цифры. Они есть? Есть у меня подозрения, что кто-то > > сильно переоценивает тормознутость оберток. Ну, ODBC, вычеркнем, конечно. > > Я вам назвал цифру - один из проектов выполняет 1 000 000 селектов в минуту. > Используется нативный tclsqlite. Притом это ничего не требует от разработчика > - оно само по себе работает с такой скоростью, без пулов запросов и т.п. > Да, в других проектах нагрузка много меньше. Нужно ли объяснять, что наличие > хорошего запаса производительности - это здорово. > > Прим.: разве что на уровне тиклевого враппера реализован кэш препаред > запросов, но он работает совершенно прозрачно для приложения. > > > > Я правильно понимаю вашу логику: скорость работы юникса зависит от > > > скорости запуска шелла, значит, надо отказаться от юникса? > > Скорость работы UNIX-а не зависит от скорости работы шела. Никак. > > От скорости работы шела зависит только всякая дурь вроде ./configure. > > > > > А вот в дебиане почему-то решили просто шелл сменить на более быстрый > > > (bash на dash). > > Это чтобы ускорить ЗАГРУЗКУ и чтобы пнуть разработчиков, чтобы писали > > хоть как-то учитывая POSIX. К скорости РАБОТЫ UNIX-а ни первое ни второе > > отношения не имеет, ни к работе ключевых сервисов, ни к интерактивной > > работе пользователя. > > Заметим, что больше всего переживаний сейчас как раз по поводу скорости > загрузки системы. Впрочем, еще раз напомню хороший пример - qmail. > Состоит из множества модулей, которые запускаются для обработки каждого > письма. Насколько мне помнится, как минимум один из самых больших архивов > рассылок интернета работает на qmail уже более 10-ти лет. > > А вы можете объяснить, откуда такой испуг при массированном запуске > приложений в линуксе - все настолько привыкли к винде? Простые тесты > показывают, что дебиан способен запустить в секунду больше приложений, > чем может выполнить запросов типичная реляционная СУБД. А реализованные > в последних ядрах техники предотвращения создания идентичных страниц > памяти позволяют и все бо`льшие бинари запускать чрезвычайно быстро > (разумеется, при том условии, что они не расшвыриваются памятью) - размер > самого кода приложения становится малозначимым фактором. > > Вероятно, надо отметить, что запускать следует все же, хорошо подумав, - > используя очередь заданий на обработку и фиксированное число обработчиков. > Имхо этот момент очевиден, но инженерные соображения сегодня зачастую > просто игнорируются, так что нелишне и напомнить, что нужно головой думать. > > Best regards, Alexey Pechnikov. > http://pechnikov.tel/ -- Oleg Tsymaenko <ts...@lafox.net> TSYM1-UANIC -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
