Re: очень хочется squirrelsh
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/
Reply to: