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/
