терапия
Сейчас этот блог в основном про психотерапию.
как правильно
Слушайте меня, я вас научу правильно жить.
психология
Буржуазная лже-наука, пытающаяся выявить закономерности в людях.
практика
Случаи и выводы из психотерапевтической практики.
кино
Фильмы и сериалы.
книги
Это как кино, но только на бумаге.
nutshells
«В двух словах», обо всем.
дорогой дневник
Записи из жизни (скорее всего, не интересные).
беллетристика
Мои литературные произведения и идеи.
духовный рост
Когда физический рост кончается, начинается этот.
дивинация
Как предсказывать будущее.
половой вопрос
Про секс и сексуальность.
заяижопа
Творческий дуэт с моей женой.
магия
«Магическое — другое название психического».
Карл Юнг
игровой дизайн
Раньше я делал игры.
игры
Компьютерные игры.
язык
Слова там всякие.
людишки
Уменьшительно-ласкательно и с любовью.
культ личности
Про великих людей (то есть, в основном про меня).
hwyd
Уникальная Система Прививания Привычек.
буклет
я
идеи
блоги
spectator.ru
дети
wow
вебдев
музыка
контент
программирование
религия
дейтинг
диалоги
яндекс
кулинария
coub
fitness
символы
йога
шаманизм
tiny
ребенок
backward2 forward3

Хорошей DB должно быть монго

14 лет назад в категориях вебдев mongodb

Много-много лет назад, великий гений, коим я, несомненно, являюсь, осознавал неуместность использования реляционных баз данных в веб-программировании и регулярно травил пхп-программистов, которые любили писать, например, логи в базы.

И действительно, даже при разработке «типа CMS» для того, чтобы по адресу /about выводился какой-нибудь текст, в 99% случаев достаточно сделать файл about.txt и пихать все туда, если надо запихать больше одного значения («текст и заголовок») — то serialize и вперед (нет, не xml и прочее гавно).

Да и вообще, CMS никому не нужны.

У меня был движок блога, «написанный на файлах» и была даже специальная кнопочка, на которой значилось «no sql». У Болка движок блога, кстати, до сих пор на файлах работает, а ведь уже 21 век на дворе.

С тех пор прошло много времени, остальное отсталое человечество дозрело и движение nosql действительно завелось и стало трендом, похуже mysql.

Я же совершенно случайно и безотносительно ко всяким трендам попробовал mongodb и полюбил.

Пользоваться mongodb надо не из-за производительности, масштабируемости, nosql (забудьте все, что я говорил выше), а только хотя бы потому, что после ее использования внутри остается теплое приятное чувство, что Сделал Всё Правильно.

В mongo можно пихать «документы», при этом документ — это массив. Поднимите руки, что любит массивы так же, как люблю их я? Ага, молодцы, возьмите с полки пирожки.

Что самое смешное — на предыдущем проекте я написал простенькую «оболочку» для mysql, которая позволяет работать с «документом», как с «массивом» (ну, чисто формально оно и сейчас позволяет, после запроса возвращается же массив? А теперь попробуйте изменить в нем одно значение и запихать его обратно, ага).

Документы не обязаны иметь строгую структуру, это называется «schema-less». Не, ну я любил заниматься анальными извращениями и решать, где для столбика в mysql хватит tinyint, а где и вовсе bit(4), но всему есть предел, к тому же после второго раза это уже не так интересно.

Тем те менее, несмотря на то, что нет «обязательных» полей, строить по ним индексы мы все равно можем. А потом искать по ним (впрочем, искать можно и вовсе без индексов, причем иногда более оптимально, чем с ними — когда требуется перебор всей таблицы, например).

Таким образом, «коллекция» в mongo представляет собой просто набор массивов, куда можно свободно писать, свободно модифицировать и свободно делать любые выборки по любому количеству полей, не хуже, чем в mysql.

Кстати, запросы для выборок — тоже массивы. Очень удобно генерировать их автоматически, не надо подставлять «SELECT .... FROM» в нужных местах, просто создал массив — и вперед. То есть, если документ-массив целиком же кинуть в выборку в качестве запроса, то он найдет и вернет самого себя (что логично), если часть документа, напимер, массив user => acerbial, то оно вернет все документы, где user => acerbial.

«Но без join-ов».

В этом — прелесть номер два. Так как пихать можно любые массивы (это называется «Document Store»), половина join-ов отпадает естественным образом.

Например, заметка и комментарии к ней — это один документ, а не 1+N запись в базе данных (где N — количество комментариев).

Учитывая, что максимальный размер документа — 4 мегабайта, и ты не обязан работать с ним целиком, не только нет причин не хранить комментарии отдельно, но это является единственным логичным и правильным способом.

Сразу решается «проблема» удаления текста и удаления комментариев к нему.

Очень просто решаются задачи, типа «закладки пользователя» — они принадлежат, натурально, пользователю.

Ну давайте уже признаем, что в вебе хранятся и выводятся документы — сразу станет легче жить.

Многие мелочи заботливо сделаны «для веба», да и просто — заботливо сделаны. У каждого документа есть автоматически создаваемый уникальный id («аналог» int autoincrement в mysql), о котором не надо заботиться — он просто есть и работает. Более того, когда ты запишешь новый документ в коллекцию, mongo вернет этот id сам, mysql же придется об этом просить отдельно.

Есть capped collection — коллекция, которая обрезает себя сама («хранить 100 последних документов»), идеально для ведения логоподобной ерунды. Есть upsert — «если документ не существует, то создать», это позволяет писать один и тот же код для создания и редактирования. (Что тоже меня всегда бесило в MYSQL — там update и insert это две разные команды).

Можно не только указать, какие поля возвращать («как в mysql»), но и обратное — указать, какие не возвращать.

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

Инъекций, как легко догадаться, тоже не существует в принципе, как можно сделать инъекцию в массив?

Mongo просто очень приятный и покрывает все потребности «домашних веб-движков блогов» лучше, чем это делает mysql.

Скорее всего, он более подходит и для «серьезных, масштабируемых проектов», но в эти дебри мне углубляться не хочется, потому что там все сводится к аргументу «99.99% стартапов никогда не умрут от излишней посещаемости, поэтому не выебывайтесь, и делайте на mysql+php».

Проблема в том, что на mysql просто физически неприятно после того, как попробовал mongo.

Главный минус — Монго пока что мало где стоит, и уж явно не стоит на хостингах за 5 баксов.

Собственно, поэтому и я агитирую — ставьте, пробуйте, требуйте в магазинах города. Так победим.

Остальные «минусы» Монго вытекают из плюсов — ну, знаете, как с девушками: «страшная, но ебливая», и являются не минусами, а «архитектурными решениями».

Например, по умолчанию Монго пишет на диск когда захочет (Mongo writes when it pleases, ага). За счет этого достигается феноменальная скорость работы (проще просто сказать «ага, записал» на очередной запрос, а записать как-нибудь потом) и феноменальное умение проебывать данные за последнюю минуту и портить всю базу, если отрубилось питание (поправимо с помощью --repair, но осадочек остается).

С одной стороны, это все поправимо, никто не запрещает делать запросы с опцией принудительной записи, с другой — в этом и прелесть, за супермегапроизводительность надо чем-то платить.

(Рекомендуемая книга — MongoDB: The Definitive Guide, хотя для начала мануала на сайте хватает «за глаза»).

0
Смотри также На заметку ссылаются Еще в категориях

Твиттер победит RSS

Я тут недавно прочитал заметку на тему «Твиттер победит RSS» от человека, который позиционирует себя, как не глупого, и долго смеялся. Аргументация все так же — «но я ведь использую это так-то и так-то». И мы очень за тебя рады!!! Проблема со всей этой синдикацией ровно одна: всем по большому счету посрать, как оно экспортируется, «чем хуже — тем лучше», чтобы не было наездов на воровство контента и не деление трафиком.

Building iPhone Apps with HTML, CSS, and JavaScript

Гамифицируйся!

Придумали «новый» тренд, называется «gamification». Вы не поверите — это тренд про добавление в (веб) проекты игровых элементов!!111 Во-первых, это напоминает бессмертное «можно добавить к игре любого жанра элементы RPG, и она хуже не станет». Во-вторых, как и все тренды, этот существует уже сто лет, но просто «слово появилось».

NoSQL

Чуть было очередной тренд не пропустил. Я так понимаю, что nosql и вообще key-value это теперь пиздец как модно. Мы же пишем свой твиттер и фейсбук, каждый второй. Скалабилити, хуё-моё. Надо озаботиться. Кто работал с сабжем (и с каким), плюсы, минусы, подводные камни?.

Arrested web development

Обещанная заметка про веб-девелупмент. Слушал (на ютубе) я как-то историю JavaScript-а в изложении одного умного чувака и плакал горькими слезами. По маркетинговым соображениям синтаксис сделали си-подобным с легким налетом Явы, впрочем, даже не синтаксис, а некоторые особенности поведения, чтобы программисты не испугались непривычного, а так же добавили всякие безумные вещи «для новичков», типа необязательных разделителей в конце строк.

ООПа

Так вот, от пхп в пятой версии уже не тошнит, все эти ООП-шные штучки используются не по назначению, но вполне по конвенциям для утаивания врагов режима сокрытия данных, организации библиотек и прочей ерунды. Ну, вы знаете. В результате синтаксис немного поменялся, а маразма стало много меньше.

«Бери и делай»

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