Центр Развития Перспективных Технологий - компания разработчик системы мониторинга товаров. Как IT компания с большим количеством данных мы используем множество NoSQL решений в своей повседневной работе. Одним из таких решений является Apache Cassandra.

Суммарно, во всех кластерах Cassandra мы храним 0.4PB данных при общей емкости 0.9PB, стабильно производим 0.7млн операций записи и доступа к данным и 1.1млн когда необходимо разогнаться в трудные времена, при этом продолжаем непрерывно расширяться.

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

Материал подразумевает, что вы уже начали знакомиться с этой замечательной базой данных, хотите найти примеры её использования в российском сегменте интернета и будет полезен тем, кто постоянно ищет способ обучиться за счёт чужих ошибок. Ошибок мы совершили не мало, добро пожаловать!

Как и у многих, в нашей компании возник вопрос импортозамещения. В целом вопрос понятный, много раз обсужденный со всех точек зрения. И вот настал счастливый момент, когда слова трансформировались в конкретные задачи с конкретными сроками. И одна из них была о замене СУБД для 1С.

Ну и конечно же, первым делом был поднят вопрос о кластеризации этой истории. Никто подвоха особого не ожидал, ибо у нас есть уже зарекомендовавшее себя решение в виде связки pg_auto_failover версии 1.6 от Citus (далее PGAF для краткости) и keepalived. Это решение нас целиком и полностью устраивает, поэтому выбор наш был очевиден.

Но когда мы начали настраивать выяснился очень неприятный момент - обычная сборка PGAF просто не работает с версией СУБД от PostgresPro - все ломается из-за жестко прописанных зависимостей. Тут то и началось "веселье".

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

Давным-давно, такие слова как "hot keys" и "keyboard shortcuts" мне не всегда удавалось перевести на русский без потери лица. Как-то раз, я написал "клавиатурные сокращения", чем сразу же привлёк косые взгляды и вызвал смелые медицинские фантазии... Но вроде бы сейчас принято везде говорить и писать "горячие клавиши". О них и поговорим.

Данная заметка — шпаргалка по линуксовой оболочке Bash. Если вам приходится часто иметь дело с терминалом в Linux (и вы не меняли Bash на другой шелл), то будет очень полезно использовать эти самые "сокращения" на благо себе и в мирных целях. Текст написан для начинающих пользователей, но кто знает — может быть и вы найдёте в нём что-то новое и полезное для себя.

Для удобства будем считать, что по умолчанию под терминалом мы понимаем стандартную в настольной редакции Ubuntu программу "Терминал Gnome".

Привет! На связи Олег Уткин из отдела архитектуры систем хранения данных Tarantool. Я хочу рассказать, как в ходе проекта для Московской биржи мы консолидировали потоки данных из разных торговых систем и наладили их доставку клиентам. По пути мы собрали много граблей и сделали несколько интересных выводов, которыми я далее поделюсь.

Доклад Алексея Лесовского про то, что нового есть в PostgreSQL в плане мониторинга.

Охватывать Алексей будет 13 и 14 версии. Далее от его лица.

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

Я составил 50 самых важных вопросов будущему работодателю, которые ты обязан задать на собеседовании.

Привет, Хабр!

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

Главная задача данной статьи – указать начинающим специалистам направление развития, дать ключевые понятия для дальнейшего изучения и показать несколько простых практических приемов. По этой причине (а еще, безусловно, вследствие недостаточной квалификации автора) теоретический материал достаточно сильно упрощен.

_{Эта статья была опубликована на SQL.RU Другие опубликованные там статьи на тему MS SQL Server можно найти в блоге https://mssqlforever.blogspot.com/ Telegram-канал блога тут: https://t.me/mssqlhelp}

По материалам технической статьи Майкрософт: A Case Study: Fast and Reliable Backup and Restore of a VLDB over the Network

^{Статья была опубликована рание на SQL.RU Публикуется повторно ввиду недоступности сайта.}

Автор: Томас Грохсер (Thomas H. Grohser)

При содействии: Линдсей Аллен (Lindsey Allen)

Техническая экспертиза статьи: Sanjay Mishra, Lubor Kollar, Stuart Ozer, Thomas Kejser, Juergen Thomas, James Podgorski, Burzin Patel

Перевод: Александр Гладченко,  Ирина Наумова

Дата издания: июнь 2009г.

Тематика статьи: SQL Server 2008

 Резюме: Размер базы данных непрерывно растёт, темп этого роста, а также её доступность и готовность фиксируется в соглашение о качестве сервиса - SLA. Одновременно с ростом повышается важность быстрого и надежного резервного копирования и планового восстановления в текущем окружении. Этот документ посвящён проблемам проектирования устойчивого резервного копирования и решений по восстановлению очень больших баз данных (VLDB). На реальном примере, в этой статье демонстрируется, как лучше всего использовать резервное копирование и возможности по восстановлению, которыми обладает SQL Server 2008, что должно помочь при создании планов резервного копирования и восстановления VLDB по сети.

Опубликовано 23 февраля 2022 года
Автор статьи Gianluca Sartori

В этой статье описывается, как отловить все запросы, выполняемые на сервере, и сохранить данные событий xEvents в таблицу SQL Server. Последнее вызывает трудности при использовании стандартных целей для сессии расширенных событиях. В документации рекомендуется использовать два возможных метода для извлечения информации из сеанса:

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

Для решения этой задачи можно строить сложные математические модели и проверять их на "кластерах с бигдатой", но мы попробуем найти вариант попроще - когда есть всего одна метрика, SQL и немного житейской логики.

Всем привет! На связи Артемий Козырь – Analytics Engineer в Wheely.

Продолжаю серию публикаций в формате “вредных советов”, целью которых является попытка обратить внимание на (не)лучшие практики и подходы в построении аналитических сервисов с реальными примерами и историями.

В этой публикации Вас ожидает:

Всем привет.

В этой публикации мы начнем рассказ о том, как наша BI-платформа «Форсайт» работает с данными. Как организовано взаимодействие платформы с СУБД и какие объемы информации мы можем эффективно обрабатывать. Что такое связка «BI+Data Lake» и как можно ее сформировать. Как в OLAP-кубах получать сведения из разных слоев данных: сырые/неструктурированные, детальные, консолидированные, валидированные, аналитические и т.п. Зачем для BI нужно деление на горячие, теплые и холодные данные. Ответы на все эти вопросы вы найдете в цикле наших статей.

Осуществлять аналитическую обработку данных, причем зачастую разной природы и масштабов – дело достаточно сложное. Поэтому мы разделили наш рассказ на несколько частей.  Итак, давайте начнем первую часть нашего рассказа. Welcome под кат!

На очереди SQL-секция конференции ЮMoneyDay, и она очень мощная, потому что уже проверена осенним митапом про базы данных. Даже если были на нём — в докладах много нового.

Начнём с антифрода: как мы онлайн и офлайн обрабатываем транзакции, храним данные на Microsoft SQL Server и используем движок Business Rule Engine. Далее поделимся, зачем мы взялись за управление метаданными и почему продолжаем развивать это направление.

Заглядывайте под кат!

По материалам статьи Esther Xin «Prevent SQL Server Dump Generation in Hot Cases: Common Ways & Scenarios»
14 ноября 2021г.
В этой статье будут описаны способы предотвращения создания дампа SQL Server для наиболее часто встречающихся видов исключений. В промышленной среде это позволит продержаться до решения проблемы, в случае, когда генерация дампов сильно мешает нормальной работе. Подразумевается, что у вас уже есть файл дампа, пригодный для расследования RCA. Также, вы должны быть уверены, что причиной создания дампов является одно и то же исключение, о чём говорит одинаковый стек вызовов для потока, приведшего к дампу.

В продуктиве, особенно когда SQL Server является частью кластера (SQL AG или FCI), в качестве быстрого решения для защиты от сбоев, вызванных процессом генерации дампа, поддержка Майкрософт может предложить рассмотреть возможность отключения процесса создания дампа.
Главной опасностью того, что файл дампа не будет генерироваться после того, как произойдёт исключение, является невозможность дальнейшего поиска и устранения проблем на основании содержащейся в дампе информации. Кроме того, само отключение возможности создания дампа не может избавить от возникновения исключения в процессе SQL Server. Применяя этот метод, будьте осторожны и учитывайте возможные риски, связанные с тем, что отсутствие дампов может ввести в заблуждение при оценке состояния сервера. Обязательно согласуйте отключение дампов со всеми заинтересованными сторонами, прежде чем вносить какие-либо изменения.
Конечно, увеличение тайм-аута проверки статуса сервера и тайм-аута проверки работоспособности может быть альтернативным вариантом реакции на череду дампов, но в типичном продуктиве в случае аварии, когда требуется быстрый отклик и быстрая отработка отказа, такой вариант не подходит (нежелательно ждать генерации дампа перед отработкой отказа или длительное создание дампа само может стать причиной отработки отказа).
Ниже показаны несколько флагов трассировки, которые позволяют отключить создание дампа в наиболее часто встречающихся случаях. В других случаях, следует обратиться к документации Майкрософт, которая описывает соответствующие флаги трассировки и поведение сервера после их включения.

Опыт показывает, что разработчики редко задумываются о проблемах, которые могут возникать при многопользовательском доступе к данным. При этом практически любое web-приложение является многопользовательским и так или иначе использует блокировки при доступе к данным в БД. При неправильном использовании эти блокировки могут больно бить по пользователям, а иногда и по системе в целом. Поэтому рано или поздно каждый разработчик многопользовательских систем должен задуматься о том, как ему начать работать с БД так, чтобы пользователи не мешали другу другу. Многие считают, что это сложно, давайте вместе убедимся, что это не так.