пятница, 11 апреля 2008 г.

Google BigTable против RDBMS

Оригинальная статья (основной посыл - Relational Databases are Dead).
Обсуждение на reddit

От себя - в этом как и в большенстве подобных случаев мало кто задумывается о сущности проблемы. Мнение первых сводится в основном к "Гугль это круто потому что Гугль это круто". Мнение вторых - "а как же без join и нормализации делать сложные запросы? Раз нельзя, значит BigTable в пролете".
Попробую собрать свои мысли на эту тему .

Пусть у нас "стандартная" база данных - products,customers,orders. Данные у нас скорее всего будут огранизованны следующим образом - таблица products, таблица customers, таблица orders, и всячиские таблица productid->orderid и т.д. Интерес представляют последнии. Зачем они собственно нужны? Ответ - время выборки. Допустим нам нужно посмотреть все заказы по данному продукту. Без таблиц типа productid->orderid это будет примерно так - берем productid, идем по всем записам в таблице orders, выбираем такие у которых совпадает productid. Время поиска O(n). При наличии productid->orderid найти все orderid у которых соответствующий productid можно гораздо быстрее. Соответственно скорость работы запроса намного больше. Как это сделать на BigTable без join запросов и первоначальной нормализаци базы? Да никак. Если все делать "в лоб" скорость выполнения запросов в BigTable гораздо ниже. Итого - BigTable в пролете?

Не совсем...давайте посмотрим на задачу повнимательнее. В первых мы говорили только о поиске и выборке. Что если количество операции "вставка" сопостовимо с количеством операций выборка? Причим количество таких операций в секунду достаточно велико? Случится неприятность...
Добавим "если". Что если обьем данных очень велик? Что если частота различных запросов различна? Что если их частота сильно различна?
Далее - что если нам не обязательно получить "точную" выборку. Приблизительная очень даже подойдет. А что если у нас нет таблицы products а есть только customers и orders/pictures/comments/...

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

Здесь важно следующее - задачи, возникающие перед современными веб-приложениями, работающими под польшой нагрузкой "классической" RDBMS решаются со скрипом. Это прежде всего потому что RDBMS не подходит для этих задач. Описать эти задачи можно так - огромный обьем данных, частые операции вставки/удаления, отсутствие необходимости в точном результате выборки (подойдет достоверный).

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

Выводы.:)

Cможет ли BigTable решать эти вопросы более быстро и качественно чем RDBMS? А не знаю я. Возможно и сможет. Даже скорее всего сможет. А если и не сможет - тогда возникнет что-то что cможет. Потому что необходимость есть...
Составляют ли подобные веб-приложения большенство? Скорее всего нет.
Найдет ли BigTable свое применение? Найдет.
Означает ли BigTable конец RDBMS? Тут однозначно нет.
Сузится ли круг задач решаемых с помощью RDBMS? Тут однозначное да. Причем не обязательно под влиянием BigTable. Есть еще in cloud computing. Или OODBMS. Или еще чего нибудь...

Комментариев нет: