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

в 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 тестовых площадок, изолированных друг от друга. Читать полностью »

в 14:08, , рубрики: cache, dbms, intersystems, release, Администрирование баз данных, Блог компании InterSystems, релиз, СУБД, субд Caché, хранение данных

Релиз СУБД InterSystems Caché 2016.2 - 1

Всем привет! Состоялся очередной выпуск новой версии Caché под номером 2016.2. Изменений не так много, но все они важные. Как всегда, вначале публикуем ссылку на полный список изменений (на английском языке).

Итак.

Читать полностью »

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

Сальвадор Дали, Дезинтеграция постоянства памяти. 1952—1954. Холст, масло.

Всем привет. Кто-то из вас, возможно, уже знаком с СУБД для данных в оперативной памяти, но на всякий случай — по ссылке можно найти их общее описание. Если вкратце, такие СУБД хранят данные целиком в оперативной памяти. Что это означает? Каждый раз, отправляя запрос на поиск или обновление данных, вы обращаетесь только к оперативной памяти в обход жесткого диска — на нем никакие операции не производятся. И это хорошо, потому что оперативная память работает намного быстрее любого диска. Примером такой СУБД является Memcached.

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

Можно ли объединить достоинства хранения данных в оперативной памяти с надежностью проверенных временем СУБД вроде MySQL или Postgres? Конечно! Повлияет ли это на производительность? Вы удивитесь, но нет!
Читать полностью »

в 7:51, , рубрики: gtd, postgres, интервью с разработчиками, Карьера в IT-индустрии, конференция для разработчиков, советы начинающим, СУБД

image

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

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

Сегодня наш гость — Олег Бартунов, генеральный директор компании Postgres Professional. В 2015 году Олег и его команда привлекли несколько миллионов долларов США на создание отечественного вендора PostgreSQL.Читать полностью »

в 11:43, , рубрики: IBM, Microsoft SQL Server, oracle, sql, базы данных, история языков программирования, разработка по, СУБД

История языков программирования: SQL- стандартизация длиною в жизнь - 1

По мнению аналитиков CodingDojo, SQL — самый важный и нужный язык запросов среди языков программирования, как бы странно это ни звучало. Рейтинг CodingDojo учитывает статистику востребованности языков программирования на рынке труда.

Ведь СУБД – MySQL, PostgreSQL и Microsoft SQL Server – распространены повсеместно: в крупном и малом бизнесе, в больницах, банках, университетах и так далее. В принципе, SQL не ограничивается только настольными девайсами: СУБД SQLite с успехом заняла свое место на Android-смартфонах и мобильных устройствах Apple. Соответственно, такие приложения, как Skype и Dropbox, постоянно к ней обращаются.

Однако были времена, когда не было смартфонов, а этот язык уже существовал. История SQL – это не годы, но десятилетия. Поверили в него не сразу.Читать полностью »

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