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



Корпоративный поиск – это инструмент для бизнеса, для сотрудников предприятия – конечных пользователей, не связанных с ИТ. В первую очередь это поиск информации на файловых серверах, где по сути нет никакой структуризации, а также поиск на таких платформах как Exchange и SharePoint. Таким образом поисковый инструмент с одной стороны должен быть простым в использовании и заточенным под корпоративную специфику, а с другой стороны должен без ущерба интегрироваться с существующими системами и регламентами, уметь индексировать множество современных форматов данных и удовлетворять многим другим техническим требованиям.

Откуда есть пошёл насущный вопрос

С ростом объёма неструктурированных данных организации вопрос управления её информационными ресурсами (в частности, распределения прав доступа) перестаёт быть простым и становится проблемой, а за определёнными пределами – перерастает в настоящий кошмар. Кое-кто наверняка помнит, что на одноимённом уровне сложности происходило с монстрами в Doom: они плодились бесконтрольно, и вопрос для 99% игроков был не в том, сможете ли вы выжить, а в том, как долго продержитесь. Примерно то же самое начинает происходить и с данными: со временем их объём не только не снижается – он растёт, причём независимо от штата организации. Количество сотрудников может даже уменьшиться, но… Папка с сочетанием «2002 год» в названии? Она нам нужна. Марья Ивановна уволилась три года назад? Не трогайте её профиль, там ценные документы. А ещё мы вот тут создадим папочку. И тут. И вот здесь тоже очень нужно…

Увеличение штата специализированных подразделений – дело само по себе затратное – не выход: прибегать к такому решению постоянно (хотя бы догоняя скорость роста данных) не получится даже при всём желании. А ведь у таких подразделений есть множество других задач, зачастую более важных и также требующих огромного времени.



Что же делать? Очевидно, нужно качественное иное решение вопроса, и цель его – куда-то переместить нагрузку, создаваемую при управлении данными. Идеально, если ресурсы для обработки такой нагрузки будут расти пропорционально её увеличению. А если помечтать – чтобы росли автоматически, без меня. Эх. … Так. Но постойте… Ведь у нас уже есть вся база для создания такой почти самобалансирующей системы!

8 августа 2014 года вышла новая версия HP Vertica 7.1. Команда Майкла Стоунбрейкера продолжает утверждать, что работа с большими данными сродни БАМу и продолжает новым версиям выдавать названия с строительной тематикой. Итак, Бульдозером (6 версия) по таблицам данные разровняли, сверху неструктурированными данными во Flex зону приложили (версия 7.0), пришла пора большого Экскаватора повернуть реки вспять. Встречаем версию Dragline 7.1! В этой статье я опишу, что же изменилось в новой версии.

Расширения функциональности проекций

Напомню для тех, кто в курсе и расскажу для тех, кто не знает: проекцией в Vertica называется материализация данных таблицы. Таблица в Vertica это описание структуры таблицы (столбцов), constraints и партиций. А непосредственно данные хранятся в проекциях, которые создаются на таблицы. Проекции чем-то похожи на индексы, они хранят данные по всем или не всем столбцам таблицы. Может быть более одной проекции на таблицу, проекции могут хранить отсегментированные и отсортированные данные по разным правилам. Данные во всех проекциях автоматически обновляются при обновлении записей таблицы. Фактически проекции содержат данные таблицы полностью всех колонок или частично определенных колонок. Жертвуется дисковое место серверов кластера, но значительно ускоряются выборки для разных групп запросов.

Выражения в проекциях

До новой версии в проекциях можно был указать исключительно только колонки таблицы. Это накладывало определенные ограничения на использование проекций. Например, если в запросах часто в фильтрации использовалось выражение по колонкам таблицы, поиск по этому фильтру не был максимально эффективным за счет того, что в проекции не было возможности указать сортировать хранимые данные по выражению. Сортировка же по столбцам выражения вряд ли помогла повысить производительность. Это могло вылиться в достаточно серьезную проблему. В качестве решения потребовалось бы добавить в таблицу новую колонку, в которую можно сохранять результат вычисления. Так же потребовалось изменить алгоритм загрузки в эту таблицу данных первоисточников, чтобы во время загрузки заполнять вычисляемый столбец. Так же пришлось бы перегружать всю таблицу, чтобы заполнить добавленное поле. Если в таблице десятки и сотни миллиардов записей и в нее идет постоянная загрузка, такое решение физически было бы невыполнимо.

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

CREATE PROJECTION sales_proj (sale_id, sale_count,  sale_price, sale_value) AS
  SELECT sale_id, sale_count, sale_price, sale_count * sale_price
  FROM sales 
  ORDER BY sale_count * sale_price
  SEGMENTED BY HASH(sale_id) ALL NODES KSAFE 1;

Следующий запрос к созданной проекции таблицы:

SELECT *
FROM sales_proj_b0
WHERE value > 1000000
ORDER BY value;

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

На такие проекции накладываются следующие ограничения:

• Нельзя использовать функции, которые могут изменить результат (например функцию TO_CHAR, так как она вернет разный результат в зависимости от выставленной кодировки клиента)
• Нельзя использовать служебные мета функции
• Нельзя обновлять записи таблицы оператором MERGE (UPDATE и DELETE разрешены)

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

Поздравляю всех с F1 — интернациональным днём помощи.

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

Предположим, что у вас есть таблица с большим количеством записей и в неё нужно добавить один или несколько индексов со следующими условиями:

1. их генерация должна быть максимально быстрой
2. чтобы генерацию можно было производить порциями.
   К примеру, если есть таблица на 300М записей и работы с ней можно производить только в нерабочее время, то чтобы можно было разбить весь процесс на три ночи по 100М записей
3. появление новых индексов и сам процесс их генерации не должны мешать текущей работе с классом/таблицей

Для этого можно было бы воспользоваться уже известным методом %BuildIndices(), но в таком случае это не будет удовлетворять нашим условиям.

Каков же выход?

Необходимость в анализе больших объемов информации быстро выходит за рамки исключительно коммерческого использования.
Big Data оказывает серьезное влияние на решения, принимаемые людьми, начиная с выборов президента и заканчивая покупкой чашечки кофе. Сфера анализа больших объемов информации стала настолько прибыльной, что инвесторы из штата Массачусетс торопятся найти очередную будущую многомиллиардную компанию, чтобы успеть инвестировать в нее сейчас.
На сегодняшний день коммерческое использование Big Data в основном существует в виде контекстной рекламы – стоит только вспомнить пророческий в этом плане сервис Google ads.

NewSQL

Начало

Сегодня очень легко наблюдать стремительный рост данных в интернете. Согласно одной оценке, данные, созданные в 2010, составляют приблизительно 1,200 ЭБ (10¹⁸ байт) и вырастут почти к 8,000 ЭБ к 2015 в Интернете, являющимся основным поставщиком данных к потребителю.

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

Пока программисты всего мира устраивают глобальные Holywars на тему: «SQL vs NoSQL», крупные компании, такие как Google и Facebook со своей миллиардной аудиторией всеми силами борются с нехваткой мощностей и предельными работами СУБД. Несмотря на появление новой технологии NoSQL, которая позволяла легко масштабировать данные, она так и не решила вопросы связанные с соответствием операций требованиям ACID (atomicity, consistency, isolation, durability — «атомарность, непротиворечивость, изолированность, долговечность») — стандарта, который гарантирует точность выполнения оперативных транзакций средствами СУБД, даже если работа системы прерывалась. На фоне всего этого компания VoltDB при поддержке нескольких других компаний, начали разрабатывать с чистого листа новый opensource проект под название NewSQL, сочетающий в себе лучшие стороны SQL и NoSQL.