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

Файлы в базе

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

Люди, которые хранят файлы в базе — больные извращенцы.

Если это MySql, хехе.

В Монго есть специальный механизм для хранения файлов в «базе», называется GridFS.

Полезностей у него минимум две:
1. Легкий бэкап кучи файлов с помощью репликации базы.
2. Все равно нужна таблица с метаинформацией к файлам, тут все хранится «вместе».

Цитата раз:

A: The nice thing about GridFS is that it streams the data back to the client, so you never need more than 4MB of memory.
Q: Now I know.

Цитата два:

There is currently no method that automatically streams chunks, but it would be fairly easy to write by querying the $grid->chunks collection.

Кто-то из них явно пиздит. Скорее всего, везде, кроме Советской России, файл и правда отдается чанками, но конкретно в PHP такого способа нет (MongoGridFSFile::getBytes() грузит файл целиком в память).

Пришлось делать как-то так, короче:

$cursor = $M[chunks]->find(array("files_id" => $img->file['_id']))->sort(array("n" => 1));

foreach($cursor as $chunk) echo $chunk['data']->bin;

В общем, я на очередном дейтинге проекте пока сделал «все картинки в базе», а там поглядим.

0

R3

10 лет назад в категориях mongodb вебдев spectator.ru

Вы, наверное, ждете, что я, как какой-нибудь Бирман, буду расписывать прелести нового движка? (Он называется, кстати, R3 — только потому, что предыдущий назывался R2).

Так вот, не буду.

В серверной части от тривиален. Нет, ну все же знают эту старую фишку, что разница эффективности программистов может достигать 20 раз, про это писали все, кому ни лень. Я не говорю, что я ровно в 20 раз эффективней остальных. Максимум в 19,95.

(Иными словами, я допускаю, что кому-то на что-то подобное потребуется 19 дней, но это не делает задачу нетривиальной).

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

И на все хватает одной «таблицы», которая называется «заметки». Удивительно!

Очевидно, что utf-8, потому что некуда деваться.

«Приводить примеры кода» просто бессмысленно, ну, скажем, выборка по тэгу делается «примерно так»:

$entries -> find (array ("tag" => "mongodb"));

Писать подобное глупо, потому что это просто обычный синтаксис выборки, — то же самое, что описывать SELECT в mysql, например.

Вся «серверная» часть занимает не больше дня (смотри про 19 дней выше), а делать блог без ояксов в наше время просто стыдно. Поэтому очевидно, что основные усилия пришлось приложить к html-ю, js и css — вещам, которые я совсем забыл/не знал. Тут тоже ничего такого нет, комментарии аяксом — тоже мне невидаль. Особенно если ты это умеешь (я не умею, но это не повод для гордости).

Прогресс не стоит на месте, сейчас даже девушка может собрать свой блогодвижок на каком-нибудь junko или boobie on trains за 15 минут, поэтому любой человек, который всерьез пишет о своем лучшем в мире движке блога сейчас (а не лет 10 назад), просто неадекватен.

0

Full Text Search in Mongo

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

Прочитал про Full Text Search в Mongo.

Это великолепно.

Нет, правда.

0

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

10 лет назад в категориях вебдев 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
Мой «Курс реабилитации людей с техническим образованием».