Данный документ представляет собой стратегию по переиндексации таблиц в крупных базах данных (VLDB), направленную на обеспечение их стабильной работы, высокой производительности и эффективного использования ресурсов.
Данная стратегия разработана с учетом специфики работы с большими объемами данных и ориентирована на минимизацию простоев системы при выполнении обслуживающих операций.
Индексы — важнейший инструмент оптимизации запросов в базах данных. В PostgreSQL одним из вариантов является хеш-индекс. В отличие от B-tree, он работает исключительно с операциями равенства (=) и использует бакеты для хранения ссылок на строки таблицы. Давайте разберёмся, как PostgreSQL управляет этими бакетами, какие особенности у хеш-индекса и в каких случаях его применение оправдано.
При создании хеш-индекса PostgreSQL применяет хеш-функцию к каждому значению индексируемого столбца. Результат хеширования определяет, в какой бакет (bucket) попадёт запись.
Многие компании продолжают активно использовать Excel и язык макросов VBA для обработки и анализа данных. Однако с переходом на отечественные офисные решения (например, Р7-Офис) появилась необходимость в разработке новых инструментов обработки данных на JavaScript.
В ЛАНИТ мы помогаем клиентам осуществить переход на Р7-Офис и создаем макросы, которые ранее использовались в Excel. Во время этого процесса наши разработчики внимательно анализировали запросы пользователей и выявили несколько общих трендов, на основе которых и был разработан наш плагин Аналитика.
На скорость написания этого текста повлияли такие непреодолимые обстоятельства как: лето, шашлычное настроение, солнце и лень обилие работы. Возможно, за несколько месяцев эту информацию в разных вариациях уже публиковали, но я честно не видел.
В этом тексте хочется подробнее рассмотреть хранение данных в PostgreSQL на физическом уровне.
Для начала определимся с общеизвестными вещами. Данные хранятся в таблицах, таблицы находятся в схемах, схемы, в свою очередь, в базах данныхЧитать полностью »
Допустим, вам нужно перенести хранилище данных из одного кластера в другой. А выключать его нельзя, потому что это может вызвать незначительный (или значительный) коллапс сервисов, которые с ним работают. В статье мы расскажем о не самом очевидном и популярном способе переноса etcd из одного облачного кластера Kubernetes в другой. Такой способ поможет избежать простоя и связанных с ним последствий. Согласно стартовым условиям, оба кластера находятся в облаке, а потому нам предстоит столкнуться с некоторыми ограничениями и трудностями — им мы уделим особое внимание.
