Банковский сектор большой и толстый, там на кучу технологий найдутся задачи :)
У меня складывает ощущение, что NoSQL чуть ли ни везде готовы продвинуть, и тут я соглашусь с главным героем статьи и считаю, что это далеко не всегда оправданно.
Оптимизатор же не просто так появился в БД :)
И нужен он больше для толстым запросам, а не выборке из 2х таблиц.
У нас например с переходом с 10го на 11.2 Оракл многие оптимизации свелись к удалении хинтов :)
Меня больше в дискуссии интересует вопрос, чем лучше NoSQL по сравнению в денормализованной классической БД.
А то что запрос с десятком join'ов медленней просто выборки из хранилища в ОЗУ и так всем очевидно.
Я поэтому Кодда и приплёл. Здравый смысл должен рулить. А подобные магазины конечно универсальны, но за это, как вы правильно заметили, приходится платить производительностью.
Но сравнивать NoSQL с подобными монстрами, это уже крайность.
Мне кажется это сомнительным плюсом(?), разбор запроса занимает мизерное время по сравнению с выполнением подавлящего большинства запросов. Сразу вспоминаются холивары по поводу print vs echo в PHP :) И имхо это уж точно не тянет на киллер-фичу.
И да пруф этого не требую ибо сейчас сам не готов предоставить ответный по RDBMS
Заметьте, снижение избыточности привело и к увеличению целостности данных за счёт нормализации.
Тот же Кодд писал о том, нормализация есть просто попытка формализовать здравый смысл.
И да, нормализованные данные удобней обрабатывать.
А денормализовать можно всегда успеть.
В БД сильно оптимизированы эти вещи. Есть возможность сделать хранимые процедуры, тогда компиляция гарантированно идёт один раз. А каким образом NoSQL избавляет от парсинга, если ты ищешь запись с определенным атрибутом?
поэтому я и упомянул чуть выше опциональную таблицу с типами атрибутов/привязкой к типу товара. По-моему, select * from product_att t where t.att_type_id = COLOR_TYPE_ID and t.str_val = 'red' при наличие банального индекса будет всяко быстрее full scan'a по нетипизированному NoSQL хранилищу. А без индекса будет ровно то же самое.
Вы у себя подобные структуры партицируем по дате. Но у нас хранится несколько другая информация. Если я правильно понимаю специфику интернет магазина в данном контексте, то есть товар, который продавался и есть тот, что продается сейчас.
И мне кажется логичным хранить «под рукой» то, что нужен сейчас (возвращаясь к партицированию по дате). Фасетный поиск в данном случае — это исторический анализ?
И это частый сценарий?
Таблица с полями а-ля num_val, str_val, date_val и индексом по product_id, опциональная таблица со связкой типа продукта и возможными атрибутами.
Выборка по product_att where product_id = 123. Чем это хуже NoSQL?
Я имел ввиду более общую задачу хранения разных тиgов объектов с набором атрибутов. Принцип партицирование зависит опять-таки от сценария использования.
А для интернет магазина big data — это сколько типов товаров/товаров? И я так и не понял, чем здесь удобней NoSQL для случая, когда БД не влезает в ОЗУ.
Речь о сферических джойнах в вакууме? Всё же зависит от сценариев использования.
Вам нужны все атрибуты сразу за всю жизнь БД (при партицировании по дате).
Почему не поддающаяся фильтрации?
Тип продукта — связь с типом атрибутов (схема) — набор значений в разных либо одной таблицах.
Чем плохо бинарное поле, если нужно в БД по каким-то (надеюсь, объективным) причинам хранить это вид информации?
это оазве не реализуется в RDBMS с гораздо меньшим количеством побочных эффектов? в чём плюс-то? тот же MySQL можно использовать как NoSQL, а вот наоборот никак.
У меня складывает ощущение, что NoSQL чуть ли ни везде готовы продвинуть, и тут я соглашусь с главным героем статьи и считаю, что это далеко не всегда оправданно.
И нужен он больше для толстым запросам, а не выборке из 2х таблиц.
У нас например с переходом с 10го на 11.2 Оракл многие оптимизации свелись к удалении хинтов :)
Меня больше в дискуссии интересует вопрос, чем лучше NoSQL по сравнению в денормализованной классической БД.
А то что запрос с десятком join'ов медленней просто выборки из хранилища в ОЗУ и так всем очевидно.
Но сравнивать NoSQL с подобными монстрами, это уже крайность.
И да пруф этого не требую ибо сейчас сам не готов предоставить ответный по RDBMS
Тот же Кодд писал о том, нормализация есть просто попытка формализовать здравый смысл.
И да, нормализованные данные удобней обрабатывать.
А денормализовать можно всегда успеть.
только непонятно, насколько надежно всё это в плане распределенных транзакций.
ну много атрибутов и что? никак не могу уловить профит, а в скайпе апрува я так и не получил
И мне кажется логичным хранить «под рукой» то, что нужен сейчас (возвращаясь к партицированию по дате). Фасетный поиск в данном случае — это исторический анализ?
И это частый сценарий?
Выборка по product_att where product_id = 123. Чем это хуже NoSQL?
А для интернет магазина big data — это сколько типов товаров/товаров? И я так и не понял, чем здесь удобней NoSQL для случая, когда БД не влезает в ОЗУ.
Вам нужны все атрибуты сразу за всю жизнь БД (при партицировании по дате).
Тип продукта — связь с типом атрибутов (схема) — набор значений в разных либо одной таблицах.
Чем плохо бинарное поле, если нужно в БД по каким-то (надеюсь, объективным) причинам хранить это вид информации?