А вы все NoSQL да NoSQL

Upd не, ну я понимаю там, допустим, для сверхбыстрых очередей сообщений всякое kyotocabinet и прочий ключ-значение типа redis как нельзя лучше справляется, но такая очередь хранилищем данных может считаться весьма условно.

Или я неправ? ;)

Концепция SQL убога по своей сути - на хранилище данных с декларативным языком возлагается имериативная задача обработки данных, отчего возникает такое убожество как PL\SQL.

То есть LINQ лучше?

Запрещаем join, весь код СУБД затачиваем на то, что таблицы абсолютно независимы от друг друга - профит.

Обзываем какой-то ID ппц каким главным, затачиваем весь код на быстрые операции по этому ID - профит.

Запрещаем идиотам нормализировать что-попало чтобы было няшно - профит.

Под профитом следует понимать хорошие циферки на бенчмарках.

Скажу банальность: есть люди, которые освоив молоток в любой проблеме видят гвозди...

Применительно к: есть люди, которые освоив noSQL, применяют к месту и не к месту эту технологию. Хотя идеальным было бы сочетание SQL и noSQL технологий (в зависимости от требований к перфомансу). Начинать надо с SQL, а затем, по ходу стресс-тестирований, отдавать часть нереляционных функций по манипуляциям с данными в noSQL-системы.

Лучше когда молотком забивают гвозди, а не припаивают SMD диоды.

Следует добавить, в NoSQL, которые в большинстве своем специализированы. И именно это можно использовать во благо

Так ведь, чтобы разработать более-менее сложную SQL базу, надо долго учиться, реляционную алгебру знать всякую, когда чего нормализовать, а когда лучше не надо…

То ли дело была Клара Клипперовна Фокс, упокой, господь, её память. Любой школьник без царя в голове писал АРМы и шел АСУчивать предприятия. :)

надо долго учиться

Для осознания простейших распределенных неблокирующих алгоритмов хватит букваря и трех классов богословского лицея?

Ога. Собираем мы так данных по парусот (или вовсе) записей в секунду на протяжении года, а потом нам говорят: а сделайте-ка вы, посоны, нам отчетов таких, таких, эдаких и вот развоттаких еще! Вы сможете!

В SQL посоны заказали пиццу и пиво, полдня посочиняли-поотлаживали запросов, напрягли сервак как следует, и требуемые отчеты были сделаны.

В NoSQL посоны сразу пошли за веревкой и мылом, потому что оказались в жёппе.

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

Посоны из NoSQL, которые не повесились из-за отчетов, на этот раз таки повесились, потому что полгода данных пошло коту в сраку.

Посоны из SQL посмотрели на качающиеся тушки и сочувственно поцокали языками, потому что потеряли всего лишь день в аналогичной ситуации, как только проблема выявилась — именно потому, что статическая типизация, жесткая схема, правила целостности, триггеры и прочие CHECK'и начали материться в логи по первой кривой записи. Их, конечно, поимели, но за день они это дело отладили и неладное устранили.

＞жёппе

язабан.

Как заметил гражданин выше, то для данных, которые по своей природе реляционные нужно использовать соответствующий инструмент. Но если у вас есть счетчик лайков, но который всем пофиг, то лучше бы его расшардить на кучу инстансов, которые хоть и не консистентны, то в итоге будут. И потом обрабатывать >100500 запросов в секунду на каждом узле.

И следует заметить, что если СУБД реляционная, то ничего не мешает ей поддерживать такую функциональность. Но почему-то кассандра и монго просто делают это лучше.

Иногда такое впечатление, что авторы и евангелисты всех этих безSQLьных баз просто не осилили SQL в свое время и не понимают толком, зачем он нужен.

Так и есть. NoSQL-ями не пользовался, но осуждаю :)

Я прекрасно помню, как выли «разработчики всяких баз данных», когда на замену xBase массово приходили РСУБД: «убогая концепция», «язык запросов не нужен», «логика в базе?», «слишком много математики», «у нас декларативщина в таблицах, и голая императивщина в коде, а у вас каша», «зачем мне учить SQL, если Lotus 1-2-3 денег приносит?», «кому нужен этот ваш ACID?».

Горизонтальной масштабируемости нет.

Ну вот например есть база данных — файловая система. SQL? Таки нет. Реляционная? Нет, таки иерархическая (или сетевая, если есть поддержка ссылок).

Предлагаешь выкинуть файловые системы и заменить на СУБД?

В nosql для этого применяют mapreduce. А это пишется и отлаживается даже проще и быстрее чем сложные sql-запросы. И, кстати, 200 записей в секунду это ничто, поэтому sql у тебя пока еще работает.

Горизонтальной масштабируемости нет.

А мужики-то и не знали

И, кстати, 200 записей в секунду это ничто, поэтому sql у тебя пока еще работает.

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

Насчет же mapreduce меня терзают сомнения: нахрена писать аггрегатные функции фактически самому, если в SQL они из коробки идут, for free?

Презентации в 99.99% случаев это вода и слова о красивых идеях, которые пока никак не реализованы. Ты лучшей дай ссылку на главу официальной документации.

ну сколько можно эту тему мусолить, воспользуйся поиском.

Краткое содержание предыдущих серий: key-value databases решают определённый класс задач, причём гораздо успешнее чем традиционные sql-базы. Вот для этих задач и надо использовать. Так же неожиданно для многих выяснилось что некоторые задачи совсем не требуют sql.

Есть ещё преимущество - простых sql-баз нет, проектирование их дело сложное, долгое и дорогое. А key-value хранилище любой ламер может сделать, причём заточенное под свои нужды.

http://www.postgresql.org/docs/9.0/static/hot-standby.html

Предлагаешь выкинуть файловые системы и заменить на СУБД?

помню, одна инновационная ос собиралась использовать такую инновационную фс

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

В пике или постоянно? Какой объем месячных данных? Насколько сложны запросы для построения отчетов?

Насчет же mapreduce меня терзают сомнения: нахрена писать аггрегатные функции фактически самому, если в SQL они из коробки идут, for free?

Оберни их в библиотеку для твоего языка, если так сложно каждый раз набрать две строки кода. Кстати, в случае с mapreduce ты ничем не ограничен и можешь код писать на _любом_ языке (гуглить mapreduce streaming mode) и использовать какие угодно правила для агрегации, а не только то, что встроено в убогий sql.

Hot Standby is the term used to describe the ability to connect to the server and run read-only queries while the server is in archive recovery or standby mode.

Ниасилил при чем тут горизонтальная масштабируемость. У меня 200 машин, я хочу на все читать и писать, а завтра у меня объем данных вырастет в 10 раз и я захочу безболезненно добавить еще 1800 машин, чтобы справиться с объемами.

nosql это не key-value, а not only sql

ну в топике речь именно о key-value («доставать умеренно быстро блобики по ключу»)

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

бэкапы рулят.

Кстати, секса с mysql и innodb мне тоже в жизни хватило (хотя не все тут согласятся называть mysql базой данных, но всё же).

Да и аппаратные глюки исключать нельзя, а так же поломку оборудования. И тут транзакции не помогут.

А потом у тебя вылетит по питанию стойка, и всю твою монгодб можно выбрасывать

Ну да. Выбросить и подтянуть с соседней реплицированной ноды.

map reduce не панацея

мы посчитали, чтоб скорость нормальная была, нам надо бы ферму из 50 среверов только для отчетов

Ну это примерно как если бы ты спросил, чем эти ваши RISC лучше CISC. Поцоны походу просто CISC не асилили ... ну и далее по тексту.

доставать умеренно быстро блобики по ключу

Ой, как ани там оказались, блобики-то? Какой идиот их туда напихал?

http://pyha.ru/wiki/index.php?title=Redis::cmd-multi

Не, ну что в нем вот такого вот, чего нет в том же PostgreSQL

man Бритва Оккама

Хотя ты и тролль, но ты во всем прав.

проектирование БД дело сложное, долгое и дорогое. А key-value хранилище любой ламер может сделать, причём будет гордиться тем, что оно якобы заточенно под его нужды.

fixed

Через страдание носкулем надо пройти. Это как ветрянка.

секса с mysql и innodb

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

вне «динамических оперденей на эрланге» жизни нет?

Расскажу я вам историю про то, как у меня была туристическая система, в которой была база туров, которая крутилась замечательной на реляционной СУБД MySQL. Крутилась медленно и неуклюже.

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

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

К тому же в CoudbDB можно спокойно хранить файлы прямо в базе данных, в то время как в MySQL нужно извращаться с хранением блобов в базе, либо со связью объектов в базе данных с объектами файловой системы.

Тег: [история успеха]

read this --> Object-relational impedance mismatch

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

use Hibernate (или какой-нибудь другой умный ORM). Будет по одному объекту «на каждый тур и на каждый отель». Работы - написать аж два бина. И ты все еще сможешь писать логику в базу, когда возникнут тормоза.

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

Что-то мне подсказывает, что ты не осилил реляционную парадигму...

postgres не маштабируем вообще. Всякие stanby-ноды - лишнее тому доказательство.

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

mysqldump же, изкоробки есть

у всяких гуглов, яндексов, твитеров и прочих фейсбуков каждый день вылетают машины, стойки и даже датацентры и при этом всё живет без всяких sql

То, что в названии NoSQL присутствует SQL это абсолютно не делает ему никакого отношения к реляционной алгебре СУБД. Это просто другая форма хранения данных и доступа к ним. Откуда вообще эта тема холиваров двух принципиально различных инструмента с совершенно различными целями применения? Вестимо от незнаний ТСов.

в CoudbDB можно спокойно хранить файлы прямо в базе данных

Из батона чёрного хлеба можно сделать троллейбус, НО ЗАЧЕМ?!

Что-то уже не первый человек говорит об «абсолютно другой области применения», но не может её назвать.

с совершенно различными целями применения?

Как же, как же.