24-го сентября в Москве состоится (https://tech.yandex.ru/events/yagosti/24-sep-2014/) встреча PostgreSQL Meetup, на которой планируется обсудить готовящийся релиз PostgreSQL 9.4. На встрече планируют быть: Олег Бартунов, Фёдор Сигаев, Александр Коротков, Николай Самохвалов, Илья Космодемьянский и многие другие известные эксперты PostgreSQL.
Примерный план:
- Обзор новинок PostgreSQL 9.4
- Подробнее о некоторых улучшениях производительности. Huge pages
- Подробнее о типе данных jsonb и соответствующих индексах
- Модуль jsquery
- История одного небольшого успеха с PostgreSQL в одной очень большой компанииВстреча состоится в офисе Яндекса по адресу г. Москва, ул. Льва Толстого, д.16, начало в 19:00. Для посещения мероприятия требуется предварительная регистрация (https://tech.yandex.ru/events/yagosti/24-sep-2014/register/). Кроме того нужно присоединиться (http://www.meetup.com/postgresqlrussia/events/206577412/) к событию на Meetup.com.
URL: https://tech.yandex.ru/events/yagosti/24-sep-2014/
Новость: http://www.opennet.ru/opennews/art.shtml?num=40617
PostgreSQL - jsonb
vs
MongoDB - bson
MongoDB рядом не валялось.
Простите, у Вас с головой все хорошо, сравнивать слона и носорога ?
MongoDB продукт совершенно для иных задач, которые перпендикулярны РСУДБ
Как-то упоминалось, что введение jsonb и доработки сделанные в 9.4 очень сильно остужают желание переходить на MongoDB и тому подобные у многих сомневающихся
Действительно, MongoDB нужно сравнивать с /dev/null
Не могу сказать, что являюсь экспертом по всякого рода БД, но нужность монги и прочих подобных вызывает у меня сомнение. Ведь реляционная структура данных намного логичнее и удобнее для восприятия. Впрочем, это ИМХО.
> Не могу сказать, что являюсь экспертом по всякого рода БД, но нужность
> монги и прочих подобных вызывает у меня сомнение. Ведь реляционная структура
> данных намного логичнее и удобнее для восприятия. Впрочем, это ИМХО.Понимаете, Вы не совсем правы. Есть задачи, когда надо хранить много неструктурированного барахла, причем делать это в режиме active:active на Н серверах и т.д.
Отличный пример такого рода - Cassandra
Есть ситуации, когда вообще хранить без гарантии сохранения, в виде key<>value (redis, memcached)
MongoDB из серии документориентированной БД, именно для хранения неструктурированного барахла (с возможность его нормального индексирования и поиска), хорошо бьется на ноды.
Короче - это как раз тот случай, когда вся мощь СУБД не нужна
А потом всплывают мелочи, которые бы надо хранить в РСУБД, и тут начинается...
Я за ASCII текст, grep и sed работают быстрее всякой вашей xyеты реляционной. =)
у БД есть идексы. Время поиска быстрее перебора. Так же поддерживается система кэша актуальных данных. И касается это не только sql, но так же и nosql (только индексы у них не такие эффективные, так как не всегда данные выровнены по границам структур).
> Время поиска быстрее перебора.Поиск - это задача, перебор - это алгоритм. Теплое и мягкое.
Кэш это ваще сказка, - сначала создаём монстроидальне базы, потом победоносно оптимизируем,
структурируем запросы, кэшируем, сегментируем, параллелизируем,... короча ИБДЯ собственно о том, что очень раздуты проекты использующие SQL.
Тот же 1С, ну когда предприятие из 1000+ человек, столько же заказчиков,
наименование продукции от ниток для шитья до танкеров,...Но блин, вебстраничка какого-нибудь дизайнера, в SQL порядка 50 записей,... ну смешно же.
на выдачу результата от работы связки Apache/PHP/SQL/HTML/JS уходит от 2 до 60 секунд,
это же пиштец. Посмотрите чудный проект katushkin.ru - тормозилово невроибенское,
40 сек. до полной загрузки страницы.