Сжатие, безусловно, есть. И даже в DB2 пятилетней давности оно было. Но максимально эффективно сжать можно только разделив данные на колонки. Грубо говоря, чем больше разнородных данных мы пытаемся сжать, тем хуже они будут сжиматься.
Если запихивать все нужные данные в индекс, то фактически это денормализация, то есть классическая схема-звездочка OLAP.
Тут есть два момента.
Запись становится дороже, а если индексов много — ох как дороже!
Нет компрессии. Вместо уменьшения объема данных мы получили серьезный прирост (ибо данные теперь многократно дублируются). Думаю, не надо объяснять, чем это плохо.
Это уже не говоря о том, что индексы (а именно B-деревья и хэш-таблицы) заточены на поиск и фильтрацию данных, а не на эффективное их хранение.
Не совсем понял, причем тут индексы. Вы собираетесь в индекс запихнуть все данные? Индекс обычно содержит указатели на физические страницы данных и позволяет данные фильтровать, однако ну НИКАК не позволит прочесть эти данные с диска быстрее. Даже если пытаться сжимать индексы (что некоторым образом реализовано в BITMAP-индексах Oracle), это не даст никакого эффекта, т.к. сами данные не сжаты.
>проблемы класса «чтобы прочитать строчку целиком надо полезть в много разных мест» не решаются никак
Не всегда и не везде физическое разделение данных плохо. Иногда данные специально размещают в разных местах для лучшей масштабируемости. Запись однозначно дороже, но чтение может обойтись дешевле.
Индексы в таких базах устроены сложнее. Приходится хранить указатель на каждый колоночный блок строки. В классическом индексе это просто указатель на строку.
Что касается Cassandra, то там, я думаю, такой запрос сделать просто невозможно, если все колонки не лежат в одной column family (тут могу соврать).
В любом случае, индексы не являются «заменой» вертикального хранилища. Это ортогональные понятия. Индексы не позволяют сжимать и секционировать данные.
То есть старую схему «просмотреть все данные в которых может быть возможность угрозы» и заэкспейпить или переделать на PreparedStatement заменяем на совершенно новую «просмотреть все данные в которых может быть возможность угрозы и закодировать все входные параметры как base64»? Это, безусловно, прорыв.
Мда. Экономия $3000 в месяц — для дата-центра это, конечно, просто фантастический выигрыш. Наверное, аккурат столько у них уйдет на регулярное сервисное обслуживание солнечных батарей.
Попытался представить себе паспортную систему или госуслуги на Joomla. Александр, Вашу бы энергию да в мирное русло!
Вы себе примерно представляете, во что выльется внедрение любой, хотя бы мало-мальски завалящей информационной системы в госучреждениях России? Кто будет бесплатно делать аналитическую работу? кто будет за бесплатно обучать пользователей? кто будет внедрять? полстраны вообще сидит на dial-up.
Какой-нибудь госсайт, который на хабре с негодованием осуждают за «распил бабла» — это крохотная вершина айсберга, и стоимость его разработки вообще малосущественна по сравнению со всей остальной работой.
Я вообще не понимаю, какой чиновник будет смотреть этот ролик после фразы «Охерел». Понятно, конечно, что цель была не привлечь чиновников, а отбить 100 тыс. показов, и в этом плане все ок (хотя Елена Беркова, думаю, поболе хитов соберет). С другой стороны, монтажная работа и общее качество — все гут.
Желание-то есть у всех, а вот возможности воспроизвести проблему — отсутствуют. У гугль даже нет версии ОС в багтрекере, о чем тут говорить? Похоже, что ребята сильно понадеялись на webkit.
А как индексы позволяют секционировать ДАННЫЕ?
Тут есть два момента.
Это уже не говоря о том, что индексы (а именно B-деревья и хэш-таблицы) заточены на поиск и фильтрацию данных, а не на эффективное их хранение.
>проблемы класса «чтобы прочитать строчку целиком надо полезть в много разных мест» не решаются никак
Не всегда и не везде физическое разделение данных плохо. Иногда данные специально размещают в разных местах для лучшей масштабируемости. Запись однозначно дороже, но чтение может обойтись дешевле.
Что касается Cassandra, то там, я думаю, такой запрос сделать просто невозможно, если все колонки не лежат в одной column family (тут могу соврать).
В любом случае, индексы не являются «заменой» вертикального хранилища. Это ортогональные понятия. Индексы не позволяют сжимать и секционировать данные.
> в подстановке в SQL-запросах всех данных в base64-представлении
Т.е. гениальность этого метода состоит в том, чтобы поменять все SQL запросы?
У электропровайдера, похоже, интереса проводить кабель такой мощности в пустыню не наблюдалось :)
Вы себе примерно представляете, во что выльется внедрение любой, хотя бы мало-мальски завалящей информационной системы в госучреждениях России? Кто будет бесплатно делать аналитическую работу? кто будет за бесплатно обучать пользователей? кто будет внедрять? полстраны вообще сидит на dial-up.
Какой-нибудь госсайт, который на хабре с негодованием осуждают за «распил бабла» — это крохотная вершина айсберга, и стоимость его разработки вообще малосущественна по сравнению со всей остальной работой.
Именно в таком стиле разработчики Chrome и отвечают.