Недавно мне надо было как можно быстрее и проще построить вебсайт-словарь. Внимание! НЕ UGC-web2.0-социальное-нечто, а словарь. То есть база состоит из айди, термина и статьи по термину, есть три типа страниц: главная — список словарей (разные языки), списки терминов одного языка с паджинатором и, наконец, страница каждого термина.
Как обычно, я, вместо того, чтобы решить задачу самостоятельно за 1 день, потратил этот же один день на рытьё всяких там stackoverflow и djangosnippets, ища готовое приложение «словарь». Стукнув к некоему мистеру django-X, я спросил: «не знаешь ли такое приложение?». Он ответил: «нет, но это на жанге в секунды делается. Кстати — заюзай MongoDB, быстрее Мускула и всё такое». Но — MongoDB это как бэ нестандарт по всем статьям: Джанга не поддерживает его из коробки, другая концепция, в которую надо вникать. В то время, как задача была, повторюсь, сделать примитивный словарик, да ещё — как можно быстрее. Как-то не вписывается сюда экзотическое решение.
И тут я вспомнил: скорость — это SQLite! Да, она сосёт на куче конкурентных запросов. Но что такое куча конкурентных запросов? В случае с селектами — это либо очень сложные и медлительные запросы, которые лочат базу на секунды. Таких у меня не предвиделось. В остальных случаях, несмотря, что каждый запрос лочит базу, за счёт большой скорости работы SQLite запросы всё равно обрабатываются быстро. Разработчики утверждают, что если брать какой-то среднестатистический сферический сайт, то проблемы могут начаться после 100К/хитов в день. Но! Какой разработчик не юзает в наши дни кеш? Я — юзаю. Так что объём допустимой нагрузки резко повышается до небес.
Ну а инсертов/апдейтов у меня на сервере и вовсе не планировалось. Единственный кейс — влив новых, многотысячных списков слов, я собирался делать вообще на локальном компьютере, а потом обновлять файл базы на сервере. Впрочем, на ум приходят типичные случаи использования даже с инсертами. Например — блог, в который пишет небольшое количество писателей.
Я опросил коллег — оказалось, что многие любят юзать SQLite как минимум, во время разработки: не надо морочиться с созданием/настройкой базы, так как это не клиент-сервер (Django, например, вообще создаёт базу из модели, думаю, и в других фреймворках сделано подобным образом). Удобен перенос проекта вместе с базой: можно просто копировать его куда хочешь, он полностью впишется в версионные системы, удобно тестировать на сервере — не придётся делать танцев с экспортом/импортом тестовых данных.
Конечно, чаще всего SQLite юзают в системах одного пользователя: базы данных Safari, Firefox, Chrome, Skype, Symbian. Но могут найтись применения и в веб проектах. Например, я точно знаю, что SQLite заюзан для вывода всей статистики админу Sutra TDS.
Часто «гуры» бездумно сравнивают SQLite с типичными базами, типа MySQL: мол, она сосёт. Такие мнения напоминают мне ошибочный диагноз врача, прописавшего женьшень от астении, так как не всмотрелся, и не заметил топора в спине пациента.
небольшой оффтопик: количество комментариев в этом посте наглядно показывает, что количество твоих читателей с IQ большим 75 стремится к нулю, поэтому заканчивай с этим гиблым делом, и пиши о содержании кофра на твоем мопеде.
Э, дарагой, зачем ошибся блогом, вах!
Да не, на календарь глянь. Отдыхают программеры. Им снятся пятничные сиськи.
Есть в SQLite свои удобства — бекапить/разворачивать легко, переносимость легкая. Единственное, вменяемой веб-морды не нашел (в SQLite Manager много косяков).
AntonYu: я юзал локальную java-прогу. А на сервере, если что, джанго даёт отличную админку. Что-то подобное может быть и в других фреймворках. Но, есесна, это всё без SQL.
На Хабре как-то (если не ошибаюсь, может и не там) была статья, там ещё настроить можно много чего, то есть ещё значительно повысить производительность. Тоже присматриваюсь к SQLite.
SQLite это хорошо, не зря например Rails по умолчанию предлагает её в development’е использовать. Приятная база для быстрой разработки и локальных задач.
Рекомендую для удобства SQLite Managet плагин под Firefox.
Жаль, что в HTML5 как веб-сторэйдж не вошел SQLite, только FF использует, остальные вроде IndexDB тянут.
MpaK: я так понял — Хром, Сафари тоже её уже давно юзают.
А вот за SQLite Manager отдельное спасибо :-) Только не разобрался как кодировку отображения поменять в таблицах.
Да, используют, но увы в стандарт HTML5 консорциум так и не прописал, опять получается «разброд и шатание» какое-то…
MpaK, ты мешаешь стандарт языка страниц с программной реализацией. Причём база идёт за движком браузера, если бы её навязывали — тогда и дижок весь пришлось бы навязывать. Никто не поддержал бы такое.
увы в новом HTML5 уже пошла мешанина не только «языка» разметки страниц, но до кучи замешали зачем-то «возню» с эффектами и т.п. Так, что уж включить какой-то SLQ92 например на базе SQLite3 тоже было бы уж не лишнее. Все равно война ведь из-за перекодировки видео для тега video идёт, всё равно что-то надо навязать.
http://habrahabr.ru/blogs/webdev/42121/
Торм, и к чему это? Ничего нового там нет, только тем, кто под виндой гонЯет сабж.
Совершенно глупое сравнение, имхо. Эти две базы для разных вещей, если для десктоп и одиночного использования, то SQLite достаточно, но если ничего серьезного (транзакции, процедуры, триггеры отсутствуют), а MySQL местами будет громоздко. Но вот для веба SQLite же никак не проканает и будет проигрывать, так как доступ к базе последовательный, нет конкурентного доступа, а это как раз самый большой показатель «комфорта» работы с вебовской базой, чем достать и записать даже скорость :)
Мрак, если хочешь сказать что-то по теме — сначала прочитав пост.
Я особо не вникал даже в неё, просто искал сейчас кое-что и наткнулся на ту статью, про которую писал выше. Вот и скинул.
samlowry, я по теме ссылки на хабре и сказал, вообще-то, на самом деле SQLite жутко тормозной, тест просто не верный, запускайте 100-500 подключений видно будет сразу кто быстрее.
Ну, знаешь. И чо дадут они? :) У типичного сеошника куча разнотипных сайтов соседсвтует. Хрена тут сгенеришь тест. Мне лень рыть, но судя по тому, что на сайте СКЛайта утверждают — большинству никогда не столкнуться с тормозами СКЛайта. На выборку, есесна.
samlowry, суть не в том, что они дадут сеошнику, хотя и сеошники разные бывают, а в том, что будет правильно сформулирован тест и даны результаты скорости работы 2х баз при равных условия и множестве конкурирующих запросов результаты будут совсем иным по тестам.
Ну и большинству не столкнутся с тормозами SQLite это ошибочное мнение, все сталкиваются, когда их Firefox начинает например тормозить, одно из мест тот же SQLite ;-)
Да мне-т что, в чём суть той статьи и идиотских тестов (что тех, что там, что других), я про жизнь. Абстрактные тесты — это для журналистов и рекламщиков.
А про «все сталкиваются» — ты доводы не такие нятянутые приводи, в Хроме чё-т не сталкиваются, а в ФФ сталкиваются… Масло масляное, я щас вышел на улицу, и спросил тайского дедушку, который продаёт серпы — даже он знает, что ФФ тормозит из-за того, что там не только экстеншны, но и туева часть кода написяна на жаваскрипте+XML. Ваще — пожамкай на ссылки в статье, какие-то пятна у тебя в знаниях. Все топовые браузеры, кроме Осла, юзают Склайт. Не говоря уж о том, что куда не харкни в Макос — юзается он же.
Но это тут вообще не при чём. Мы про вебсервера, на которых Мускул пукнуть не может ради мелкого сайта, выбирая ахрененные джойны для другого сайта.
Хе, прочитал ща про локи при чтении — все про них говорят, но никто не шарит, что это такое. Лок при чтении SHARED, даёт любому другому процессу смело читать базу. По-русски: если нет изъёбских SELECT-ов, SQLite практически равна файлам по скорости!
Я сказал одно из этих мест. Одна и та же СУБД может работать по разному в одной и той же задачи лишь потому, что сама БД спроектирована не совсем удачно.
JavaScript + XML — это называется XUL для покрытия «пятен» ;-)
Про тему веб-серверов и отсутствие возможности пукнуть у MySQL я не понял, чуть выше это проблема не всегда СУБД, а разработчика, который не умеет проектировать БД. Как пример я бы сказал, что глупо было бы использовать для нагруженного хотя бы в 50-100 соединений веб-ЧАТА базу SQLite, глупо и MySQL, но последний с persistent connections еще потянет, а еще правильнее например бы брать тот же Memcache (я бы взял Redis) и тупо бы раз в 10-15 минут делать слив в MySQL.
Это к тому, что база SQLite это сродни блокирующимся файлам, вот http://rgrb.ru например, тут вообще файловая база, понятно, что пиков нет и всё хорошо, но если бы было 50-100 посящений в минуту то lock файловой базы (а это тоже самое что и SQLite делает) кладёт сайт намертво :)
Я просто сталкивался с такой ошибкой, когда делали кэш MySQL огромных выборок и результатов в SQLite 2 (давно это было). Это было хуже чем держать в памяти :)
SQLite не спорю хороша для встроенных однопользовательских приложений, но тогда и сравнивать с MySQL глупо, так эту СУБД чаще используют в ином подходе, где она не страдает от юной сестры проблными затыками файловой системы.
Ты меня уморил. Зачем ты жуёшь всё, чему я подвёл итог в статье? Начни с первых строк заметки — У МЕНЯ СТАТИЧНАЯ БАЗА, без апдейтов в неё. Всё! Какие файловые локи? Я говорю об этом и только об этом.
И, кстати, я не осилил — почему для кеша выборок не покатил СКлайт? Если вы часто его делали, и делали в один и тот же файл — оно ясен пень, что не сработает, да, тут будет лок, но это и дураку понятно. Или ты меня хочешь действительно удивить, и в течении, допустим, дня, база, в которую никто не писал, не выбиралась?
ЗЫ: про XUL даже не подъёбывай, я делал 2 экстеншна, и XUL первое слово, которое всплыло у меня в голове, но что-то в Википедии, при чтении об ём по диагонали, ни слова о javascript не было.
Именно, файлам :) flock( fh, LOCK_EX ) и подждем…
Это сродни таблицам MyISAM, когда лочится она вся, так и у SQLite лочиться весь файл базы (у них база прям в файле).
В общем на задачах embed db SQLite на однопользовательском подключении может выигрывать, но в многопользовательских подключения будет провисать, весь это файл кэш не поможет, маппинг в память нужен и сервер очередей, но тогда мы и MySQL получим.
Мрак, цифры из пальца высосал? :)
Вот тут наплывами бывало гораздо больше 100 посещений в минуту — http://mobidrive.ru/
Вообще никаких проблем.
Строчка Daos работает на файлах.
http://brokenbrake.biz/2010/10/16/refactoring-Daos-RW-func-2
Ну и я стресс-тестирование проводил на приличных нагрузках с помощью ab — да, тормоза были, но уж не ложился сайт.
Ага, и ваще — «покажи мне свой Alexa traffic rank». А то я уже устал слышать слово «хайлоад» от русских девелоперов, которые хайлоад видели только в сферических тестах.
Гык, про фому и ерему :) Да, я уже отошел от твоего простенького примера со словарём для которого и база-то не нужна :) простого варианта Беркли бы хватило подобия… Я говорю, про выше ссылку Тормоза, тестирование и сравнение 2х баз.
Про кэш объясняется просто, пока один человек хотел получить данные из кэша, другой был в ожидание на файловом локе. У SQLite нет менеджера очередей и каких-то асинхронных механизмов, идея провалилась и всё было в проекте переписано в тупо создание статичных html + ssi для отдачи веб-сервером, решило все проблемы на время обильных возлияний пользователей.
А так, в целом поздравляю со знакомством с SQLite
зы. Ни XUL’ом едины ;-)
Я-таки опять не осилил: откуда лок-то? Если и было — то щас нету:
А то я могу сказать, как в 1995 году на всю жизнь разочаровался в PHP — там же ж ничо нельзя делать, так, шаблоны только… И как только люди пишут на PHP?
Сэм, ты что, русские разработчики знают про великий и ужасный Хабраэффект, который ложит все их сайты на раз! Так что о хайлоаде они знают не по наслышке…
Не, я серьёзно… Мне кажется, помешательство на хайлоаде — это болезнь идеалистов.
Тормоз, цифры из пальца конечно :) не минутные тесты, в секунду и железо.
samlowry, покажите мне ваш мандат и я буду разговарить с официальным лицом (ц) что-то из классиков
проект канул в лету, но был вот он http://allufa.ru в один периодов предвыборной гонки был огромный наплыв как ботов, так и ДДосов, чем не хайлоад… были еще проекты, но затухли, например http://mirovoefoto.ru увы конкурс прошел и стал не интересен устроителям
Увы жаль mod_perl’овых проектов рабочих не сохранилось, очень интересные были эксперименты там с БД как раз.
Я тоже не понял, про какой лок речь. Мрак, SQLite можно настроить так, что блокировка будет только на время записи.
samlowry :))) ирония смешная штука, но я никогда шибко не писал на PHP и всегда не в восторге от языка, я пишу на Perl и на данный момент на Ruby, это к слову :)
Как люди пишут на PHP я тоже не понимаю, но пишут же ))
В 2004м вышли первые подверсии 3. Отстаааал, отстаааал…
Кстати, как перлист, скажи-к, а есть какие-то акселераторы перлкода для сайтов? Бегает под перлом один, переписывать — лень. А иногда вижу, что грузит…
Тормоз, возможно, за тройкой уже не слежу, мой опыт на 2ой версии.
Уверен, что сайтик allufa побил все рекорды черезжопности. И «мировое фото» тоже. НУ НЕВОЗМОЖНО ТАК ТОРМОЗИТЬ, даже если хостинг совсем отстой.
«Жителем Непала признаётся только человек зачаты непальцем и непалкой.»
Ну и что ты тут доказываешь тогда? Статью даже не прочитал, не извлёк оттуда основное, а туда же — хаять SQLite, вместе со стадом :)
Тормоз, х.з. что щаз к сайту этой 3ей версии allufa на WP не имею отношения. Второй может тоже тормозит у кого-то, у меня например из Тая даже летает в общем-то :) это вопрос к каналам, сервер вообще не нагружен уже
Тормоз, гык, говорю о плохо проведенном тестировании и точка.
samlowry, ты не поверишь сколько лет люди занимаются веб-программированием :) а уж как не любят они сразу новые бета штуки внедрять :)
Дак я сам его заюзал тока щас, хотя слышал именно из-за представления ГУглом на каком-то девелоперс дее ещё хз когда. Но повальное включение его во все _веб_ языки и фреймворки как бэ подразумевает собой шо-та…
samlowry, ну такого понятия нет, это для PHP его в опкод загоняют, чтобы потом легче запускать было.
У Перла есть отличная штука mod_perl где после запуска скрипт откомпиленный в памяти останется, для перехода с CGI — Apache::Registry модуль, он не требует изменения кода приложения (а то мало ли утечки имеют место расти в неаккуратном коде), а оборачивает сам его внутрь.
Да у меня вроде мод модперлом всё :o|
samlowry, ну понятное дело, что попробовать всё надо :)
мне просто кажется, что его тыкают почти всегда, потому как удобно его с собой брать, кинул dll’ку и вперёд, открыл файл базы, это действительно удобно :) если не надо супер производительности :)
Ну раз уж начали оффтопить. Мрак, с чего посоветуешь начать изучение «Рубина»?
А что грузит тогда, процессор, памяти жрёт много или еще чего?
Проц-с. Эхх, код ворошить надо…
Тормоз, надеюсь Сэм нас за оффтоп не забанит
Это мои Гуглридер подписки, есть и уроки и скринкасты и новости — https://www.google.com/reader/bundle/user%2F09600878815550570378%2Fbundle%2FRuby
Но в целом приятнее наверное с бумаги, я читал Фултона — Язык программирования Руби, чтобы понять сам язык, ООП (кстати, ооп схож чем-то с JavaScript + Perl)
А потом уже видимо стоит браться за Rails 3, скоро новое издание будет Agile Development in Ruby on Rails в сети проскакивала бета книжки.
samlowry, ну если проц, то действительно только код, или на С переписать (PerlXS для взаимодействия есть)
Забаню и разбаню…
:) интересный ход
ну всё, господа гусары, сегодня тайское солнце давно село, а мы о каких-то базах данных в 2 часа ночи гусарим, пойду-ка я пожалуй-с
Спасибо! А «Рельсы» я может даже и не буду изучать. Так только, любопытство удовлетворить — посмотреть, что и как они сделали. Настороженно отношусь ко всяким каркасам.
Блин, а у меня на хостинге SQLite не подключен, оказывается :( Вообще даже PHP жёстко собран без его поддержки. Жаль. В моей голове разрушен миф о том, что SQLite встроен в PHP по-умолчанию.
Предлагаю посмотреть бесплатный инструмент — Valentina Studio. Супер вещь!!! Очень рекомендую — best manager for SQLite!!! http://www.valentina-db.com/en/valentina-studio-overview