Re: очень хочется squirrelsh
о сравнении 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 <tsyma@lafox.net> TSYM1-UANIC
Reply to: