Александр Горный (gornal) wrote,
Александр Горный
gornal

Category:
  • Mood:
  • Music:

Веб-технологии для чайников - 4. Базы данных

Спасибо за ваши поправки!

Ещё один важный для успеха проекта выбор — выбор технологии хранения данных, и этот выбор, пожалуй, более важен, чем выбор языка программирования. Пользователь при работе с сайтом (или редактор при работе с административным интерфейсом) вводит какую-то информацию и эта информация, во-первых, должна надежно храниться, а во-вторых, быстро и удобно использоваться программным обеспечением нашего сайта.

Абсолютно доминирующая на данный момент концепция решения этой задачи (не только в Web) — реляционные базы данных. С точки зрения реляционных баз данных, вся информация представляется в виде таблиц, в которых столбцы это свойства объекта реального мира, а строки — сами объекты. На пересечении столбца и строки при этом может быть одно и только одно значение. Каждая таблица соответствует одному типу сущностей, а в базе данных столько таблиц, сколько нужно для представления всей предметной области. «Кадровый» состав школы, например, может быть представлен следующим набором таблиц.

Учителя
id
Фамилия
Имя
Отчество
Пол
Номер Паспорта
...
Дата Рождения
1
Иванова
Дарья
Николаевна
Ж
1111 454667
...
01.05.1960
2
Петров
Александр
Сергеевич
М
2222 645647
...
02.07.1974
...
...
...
...
...
...
...
...
45
Дмитриев
Алексей
Федорович
М
3333 877355
...
03.09.1980

Классы

id
Номер
Буква
Классный руководитель
1
1
а
1
2
1
б
45
...
...
...
...
37
11
б
2

Ученики

id
Фамилия
Имя
Отчество
...
Класс
1001
Денисов
Владимир
Анатольевич
...
1
1002
Филатова
Мария
Семеновна
...
1
...
...
...
...
...
...
2678
Волков
Вадим
Георгиевич
...
37


В принципе, значительная часть реального мира ложится на такой способ представления достаточно хорошо. Специальные программы — Системы Управления Базами Данных (СУБД) — предоставляют программисту возможность хранить и использовать данные в таком и подобном виде. Различных СУБД в мире существует достаточно много, у каждой естественно есть свои достоинства и недостатки.
Наибольшую популярность в веб-разработке получила СУБД MySQL. Главные её преимущества — бесплатность (платные варианты лицензии есть, но с их использованием в вебе я не сталкивался), простота и производительность в простых случаях. С моей личной точки зрения, количество обоснованных исключений из правила «из всех СУБД нужно выбирать MySQL» измеряется единицами на весь Рунет. К недостаткам MySQL обычно относят довольно ограниченные возможности (это действительно очень простая СУБД), низкую надежность и проблемы со скоростью работы в сложных случаях. Всё это правда, но всё это можно скомпенсировать правильным использованием, в то время как плюсы MySQL'я абсолютны и достойного ответа у конкурентов нет.
Видимо, вторая по популярности в Вебе СУБД это PostgreSQL. Как и MySQL она бесплатна, но обладает значительно большой функциональностью (хотя с другой стороны, как минимум двух абсолютно необходимых вещей, имеющихся в MySQL, в ней нет). Мой личный опыт говорит, что проблемы с производительностью в PostgreSQL фатальны и применять его в более-менее больших проектах нельзя ни при каких условиях. Я знаю специалистов с другой точкой зрения. В любом случае, никем не оспаривается то, что PostgreSQL существенно более сложен в обслуживании и использование его в проекте накладывает дополнительные требования на персонал.
Ещё более сложные (и, насколько я могу судить, ещё более редкие в использовании) СУБД это сложные платные системы, в первую очередь Oracle, DB2, Informix. У них есть урезанные бесплатные лицензии, но обычно уж если их использовать, то правильнее покупать. Видимо, из этого класса систем почти всегда следует выбирать Oracle в силу наибольшей распространенности (и соответственно наибольшего числа доступных специалистов). В любом случае, все они крайне сложны и дороги в обслуживании, их использование должно быть оправдано какими-то крайне вескими причинами.
На Windows платформе есть ещё одна альтернатива — MS SQL, по возможностям и распространенности он вполне соизмерим с Oracle. Кстати, важно отметить, что база данных и веб-сервер могут работать на физически разных компьютерах под управлением разных ОС и, например, сочетание Windows-C# и Unix-MySQL является экзотическим, но не невозможным.

Случаев, когда СУБД не подходят и данные надо хранить как-то иначе, в вебе не так уж много, но тем не менее, они встречаются, можно выделить не менее трех групп таких случаев.

Во-первых, это картинки, видеоролики, архивы и прочие файлы, которые имеют смысл именно как отдельные файлы и никак или почти никак не обрабатываются изнутри. Хранение их самих в базе данных будет лишним усложнением доступа, в базе данных хранят обычно информацию о них (автор, название, теги, ...), а сами файлы просто «как есть» кладут на диск.

Во-вторых, текстовые или почти текстовые данные, в которых требуется поиск с учетом релевантности, морфологии, выделения сниппетов и прочих алгоритмически сложных требований. Все СУБД пытаются предоставить такую возможность, но на данный момент ни у кого толком не получается. Соответственно приходится использовать отдельные системы и их механизмы хранения. Стандартным эрзац решением для красивого поиска по текстовым данным является следующее: тексты все-таки хранятся в СУБД, это позволяет удобно для программиста организовать хранение, добавление, редактирование и остальные необходимые операции. А раз в какое-то время они копируются («индексируются») в поисковую систему, которая используется только для поиска. Самой популярной на данный момент такой системой, видимо, является Sphinx.

В случае невероятно большого объёма данных СУБД может не справляться (или, что тоже самое, требовать совершенно неразумное количество железа для обработки данных). Тогда приходится писать собственные системы хранения, которые за счет специфичности будут работать в порядки быстрее. Но для оправдания такого решения должны быть действительно невероятно большие или крайне специфичные объёмы данных; обоснованные примеры такого подхода это поиск Яндекса, почта Mail.Ru и подобные проекты.

В некоторых нетипичных случаях (в основном, связанных опять же с очень большим объёмом данных проекта проекта или колоссальной нагрузкой) имеют смысл две технологии выпадающие из общего ряда: Sqlite, ещё более простая СУБД, чем mysql, и Berkley DB, система хранящая не таблицы, как все СУБД, а только пары «ключ»-«значение». Обе достаточно широко применяются вообще, «в мире», но для веба всё-таки экзотика.

Очень важно понимать, что выбор системы хранения данных и проектирование конкретной структуры это самый ответственный и важный этап разработки сайта. Ошибки, допущенные на этой стадии, крайне тяжело исправляются, т. к. обычно требуют, во-первых, переделки значительной части кода (ведь почти весь код так или иначе работает с данными), а во-вторых, перестройки уже накопленных данных, что часто сопровождается вынужденным простоем сервиса. Вообще, любое изменение (не обязательно исправление ошибки), затрагивающее структуру базы обычно требует на порядок больше работы, чем аналогичное, но укладывающееся в старую схему. Простой пример: если на школьном портале, построенном по нашему примеру базы, потребуется рядом с фамилией учителя выводить номер его паспорта, то это работа программисту на полчаса, потому что все данные в таблице уже есть. А вот если вместо номера паспорта понадобится количество учеников в ведомых им классах, то программирование легко может растянуться на дни.
Кроме того, в типичном случае, 90% времени генерации страницы на сервере это именно ожидание результатов работы СУБД, а 10% собственно работа программного кода. Т. е. в два раза менее эффективный код замедлит работу сайта на 10%, а в два раза менее эффективная база данных — в два раза.

С другой стороны, несмотря на важность и ответственность, проектирование хранилища — работа не объёмная. В большинстве случаев эксперт может её выполнить за считанные часы, получив на выходе либо готовую подходящую структуру, либо несколько условно равноправных вариантов. Ещё дни (но не месяцы и не недели) могут потребоваться на написание тестирующих эти варианты скриптов, если их действительно оказалось несколько и эффективность надо проверять (а не просто заранее очевидны нефатальные недостатки каждого). Исключения, требующие существенно большого времени на проектирование, по количеству и качеству примерно соответствуют исключениям из правила «СУБД подходят всегда».
Tags: в теории теория и практика совпадают
Subscribe

  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 102 comments