Рубрика «СУБД» - 12

в 17:01, , рубрики: clickhouse, olap, sql, Анализ и проектирование систем, высокая производительность, СУБД

ClickHouse: очень быстро и очень удобно - 1

Виктор Тарнавский показывает, что оно работает. Перед вами расшифровка доклада Highload++ 2016.

Здравствуйте. Меня зовут Виктор Тарнавский. Я работаю в «Яндексе». Расскажу про очень быструю, очень отказоустойчивую и супермасштабируемую базу данных ClickHouse для аналитических задач, которую мы разработали.

Пару слов обо мне. Я Виктор, работаю в «Яндексе» и руковожу отделом, который занимается разработкой аналитических продуктов, таких как «Яндекс.Метрика» и «Яндекс.AppMetrica». Я думаю, многие из вас пользовались этими продуктами и знают их. Ну, и в прошлом, и по-прежнему пишу много кода, а раньше еще занимался разработкой железа.
Читать полностью »

в 16:40, , рубрики: clickhouse, lifestreet, open source, sql, Yandex, СУБД

Переезд на Yandex ClickHouse - 1

Александр Зайцев отвечает на вопросы относительно переезда на Yandex ClickHouse. Это — расшифровка доклада Highload++ 2016.

Всем здравствуйте! За эти два дня на конференции было два двухчасовых митапа, сегодня даже почти трёхчасовой митап по ClickHouse. После этого Виктор с Алексеем сделали замечательный доклад, казалось бы — больше уже ничего не расскажешь. На самом деле это не так.

Я вам расскажу, как на ClickHouse переезжать, если у вас уже что-то есть. Обычно если ничего нет, то всё очень просто. Берёте и строите на новой системе. А вот если что-то есть, то это гораздо сложнее. Сейчас у вас всё хорошо. Вы поняли, что ClickHouse замечательная система. Виктор с Алексеем ответят на все вопросы, я не сомневаюсь, чтобы ещё больше уверить вас в том, что это правильное решение.

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

Всё это совершенно новый достаточно специфический опыт, он требует большой работы для того чтобы всё получилось хорошо. Какие-то простые вещи работают сразу, например, логи загрузить. А какие-то не очень простые вещи работают совсем не сразу. В конце концов, я убеждён что у всех всё получится, потому что у нас получилось. Мы прорвались через все препятствия.
Читать полностью »

в 10:01, , рубрики: Cloud Spanner, Google Spanner, NewSQL, nosql, sql, TrueTime API, Администрирование баз данных, Облачные вычисления, СУБД, хранилища данных, метки: ,

Google запустила бета-версию Cloud Spanner — СУБД поколения NewSQL - 1

Google открыла для всех бета-версию сервиса Cloud Spanner, глобально распределённой высокомасштабируемой мультиверсионной NewSQL БД с поддержкой распределённых транзакций.

Несколько лет Google использовала этот сервис исключительно для внутренних нужд. На нём работают ключевые системы Google, в том числе AdWords и Google Play. Spanner — эволюционное развитие NoSQL-предшественника Google Bigtable. Сам же c Spanner относят к семейству NewSQL-решений, то есть оно сочетает в себе преимущества реляционных и нереляционных СУБД. Это ACID-транзакции и SQL-синтаксис традиционных СУБД без ущерба для горизонтального масштабирования и высокой доступности, присущих NoSQL.

Исходя из опыта работы системы внутри компании, Google предлагает клиентам аптайм 99,9999% (шесть девяток, то есть максимум 31,5 секунды простоя в год), клиентские библиотеки с поддержкой Java, Go, Python, Node.js и др.
Читать полностью »

в 11:30, , рубрики: data, SaaS, Администрирование баз данных, бд, Блог компании Inoventica Services, дата-инженер, инструментарий, инструменты, обработка данных, перевод, разработка, Сетевые технологии, СУБД, хранение данных, хранилища данных

image

Я присоединился к команде Facebook в 2011 году в качестве инженера бизнес-аналитика. К моменту, когда я покинул команду в 2013 году я уже был дата-инженером.

Меня не продвигали или назначали на эту новую позицию. Фактически, Facebook пришла к выводу, что выполняемая нами работа является классической бизнес-аналитикой. Роль, которую в итоге мы для себя создали, была полностью новой дисциплиной, а я и моя команда находились на острие этой трансформации. Мы разрабатывали новые подходы, способы решения задач и инструменты. При этом, чаще всего, мы игнорировали традиционные методы. Мы были пионерами. Мы были дата-инженерами!

Дата-инжиниринг?

Наука о данных как самостоятельная дисциплина переживает период отроческого самоутверждения и определения себя. В тоже время дата-инжиниринг можно было назвать ее «младшим братом», который тоже проходил через нечто подобное. Дата-инжиниринг принимал от своего «старшего родственника» сигналы, искал свое место и собственную идентичность. Как и ученые, занимающиеся обработкой данных, дата-инженеры тоже пишут код. Он является высокоаналитическим, с большой долей визуализации.

Но в отличие от ученых, работающих с данными и вдохновленными более зрелым прародителем сферы — программированием — дата-инженеры создают собственные инструменты, инфраструктуру, фреймворки и сервисы. На самом деле, мы намного ближе к программированию, чем к науке о данных.
Читать полностью »

в 16:05, , рубрики: информатика, облачные сервисы, Программирование, СУБД, уроки программирования

На Code.org у детей не сохранилась домашняя работа: кончился 32-битный индекс - 1
Задание из вступительного курса «Введение в информатику» на платформе Code Studio

Сайт для обучения программированию Code.org попал в неловкую ситуацию. Из-за «технических проблем» на платформе Code Studio утром 20 января с 9:19 до 10:33 PST работы школьников по программированию — весь написанный код и другие действия на сайте — не удалось сохранить.

Технический директор образовательного сайта Джереми Стоун (Jeremy Stone) оперативно опубликовал объяснение произошедшего: «До нынешнего времени мы хранили работы по программированию учеников в таблице с 32-битным индексом, — написал он. — Эта база данных может хранить только 4 млрд строк информации об активности. Мы не осознавали, что приближаемся к этому лимиту, и таблица заполнилась».
Читать полностью »

в 4:40, , рубрики: C, postgresql, r-tree, spatial index, SPI, zorder, Алгоритмы, Геоинформационные сервисы, СУБД
Z-order vs R-tree, продолжение - 1

В прошлый раз мы пришли к выводу, что для эффективной работы пространственного индекса на основе Z-order необходимо сделать 2 вещи:

  • эффективный алгоритм получения подинтервалов
  • низкоуровневую работу с B-деревом

Вот именно этим мы и займёмся под катом.
Читать полностью »

в 15:48, , рубрики: oracle, sql, базы данных, конкуренция, ларри эллисон, реляционные базы данных, СУБД

image

До середины 70-х годов информация в базах данных распределялась по старинному иерархическому, или «древовидному», принципу, который до сих пор используется в настольных операционных системах.

Первые прототипы реляционных СУБД существовали уже в 70-е годы ХХ века. Однако мало кто верил в возможность добиться эффективной реализации таких систем. Тем не менее, к концу 1980-х годов реляционные системы заняли на мировом рынке СУБД доминирующее положение.

В связи с этим многие компании стали позиционировать свои СУБД как «реляционные» в рекламных целях. Но далеко не всегда они имели для этого достаточно оснований. Поэтому автор реляционной модели данных Эдгар Кодд в 1985 году опубликовал свои знаменитые «12 правил Кодда», которым должна удовлетворять каждая РСУБД.

Одним из первых прототипов реляционных баз данных была система System R. Это проект компании IBM, который появился в 1976 году. Он вдохновил будущих основателей Oracle на создание собственной реляционной СУБДЧитать полностью »

в 15:32, , рубрики: mail.ru, Анализ и проектирование систем, Блог компании Mail.Ru Group, высокая производительность, ОЗУ, СУБД
Асинхронная обработка запросов в СУБД в памяти, или как справиться с миллионом транзакций в секунду на одном ядре - 1

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

В этой статье я хотел бы затронуть проблему производительности СУБД в оперативной памяти. Давайте начнем обсуждение производительности с простейшего случая использования, когда просто изменяется значение по заданному ключу. Для еще большей простоты предположим, что серверная часть отсутствует, т.е. не происходит никакого клиент-серверного взаимодействия по сети (дальше будет понятно, зачем мы это сделали). Итак, СУБД (если ее можно так назвать) находится полностью в оперативной памяти вашего приложения.
Читать полностью »

в 11:38, , рубрики: mail.ru, Анализ и проектирование систем, Блог компании Mail.Ru Group, высокая производительность, ОЗУ, СУБД
Как избежать скачков во времени отклика и потреблении памяти при снятии снимков состояния в СУБД в оперативной памяти - 1

Помните мою недавнюю статью «Что такое СУБД в оперативной памяти и как она эффективно сохраняет данные»? В ней я привел краткий обзор механизмов, используемых в СУБД в оперативной памяти для обеспечения сохранности данных. Речь шла о двух основных механизмах: запись транзакций в журнал и снятие снимков состояния. Я дал общее описание принципов работы с журналом транзакций и лишь затронул тему снимков. Поэтому в этой статье о снимках я расскажу более обстоятельно: начну с простейшего способа делать снимки состояния в СУБД в оперативной памяти, выделю несколько связанных с этим способом проблем и подробно остановлюсь на том, как данный механизм реализован в Tarantool.

Итак, у нас есть СУБД, хранящая все данные в оперативной памяти. Как я уже упоминал в моей предыдущей статье, для снятия снимка состояния необходимо все эти данные записать на диск. Это означает, что нам нужно пройтись по всем таблицам и по всем строкам в каждой таблице и записать все это на диск одним файлом через системный вызов write. Довольно просто на первый взгляд. Однако проблема в том, что данные в базе постоянно изменяются. Даже если замораживать структуры данных при снятии снимка, в итоге на диске можно получить неконсистентное состояние базы данных.
Читать полностью »

в 7:05, , рубрики: Delphix, Администрирование баз данных, база данных, Блог компании КРОК, инфраструктура, ит-инфраструктура, программно-определяемая СХД, системное администрирование, СУБД, СХД, тестовые стенды, хранение данных

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

Что вы сделаете? Ну, традиционный путь — взять ещё одну хранилку на 30–35 Тб (но подешевле раз в пять, помедленнее, попроще, без резервирования) и отреплицировать базу на неё. А затем работать с копией. Хороший план?

Нет. Дело в том, что когда у вас несколько команд разработки (а в нашем случае их количество выросло от 4 до 10), нужно, соответственно, от 4 до 10 тестовых площадок. Или даже больше. Покупать такое железом просто нереально, поэтому нужно решение, которое позволит один раз реплицировать боевую базу, а затем «показывать» её каждому серверу как отдельную тестовую, но храня все изменения тестовой площадки. Вот так:

«Пьяная» база данных: как на 1 базе мы сделали 7 тестовых площадок, причём у каждой — свой собственный инкремент и дифф - 1

Расскажу, как на одном узле с физической базой мы развернули 7 тестовых площадок, изолированных друг от друга. Читать полностью »

1...111213...18
Главная   |  Архив новостей  |   Android  |   Google  |   Apple  |   Microsoft  |   Информационная безопасность  |   Веб – разработка
Публикации RSS  |  Комментарии RSS
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js