Для студентов РУДН по предмету ДругиеИнтеграция Hazelcast в сервер федеративных запросовИнтеграция Hazelcast в сервер федеративных запросов
2024-06-292024-06-29СтудИзба
Курсовая работа: Интеграция Hazelcast в сервер федеративных запросов
Описание
Содержание
2
Введение
С каждым годом становится все больше различной информации равно, как и людей, ответственных за работу с разрастающимися базами данных, их поддержку и улучшение производительности. Но у вертикального улуч-шения производительности существует потолок, после которого добавление новых мощностей дает незначительный эффект – тогда появляется смысл
Можно делать базы данных распределенными, балансировать нагрузку на сервера, доступ к удаленной базе все равно зачастую являются узким местом системы. Поэтому появилось кэширование – сохранение последних запросов или конкретных таблиц в оперативной памяти, чтобы для попу-лярных поисковых запросов и сущностей не обращаться к базе данных. Однако и у кэширования несложно найти недостатки: даже если иметь мощные сервера с большим количеством предзагруженных в кэш данных (что называется ”прогрев”), то по этим данным нельзя строить сложные запросы с фильтрами, потому что обычный кэш не гарантирует хранение всех данных конкретной сущности и что они не успели устареть.
Эта проблема решается паттернами доступа к источникам данных: write-through (запись в промежуточный узел – например, кэш – вызывает ав-томатическую запись в источник данных), write-behind (то же самое, но асинхронно), read-through (если на конкретный запрос не известно, хра-нится сущность или нет, то промежуточное звено обращается к источнику данных и запоминает результат) и другими вендор-специфическими шаб-лонами. Но хранить всю информацию на одном сервере, тем более, в опе-ративной памяти, может стать слишком большой нагрузкой, поэтому важ-на возможность распределять информацию по различным узлам, которые смогут координированно и консистентно ею управлять; и раз есть запрос на обработку более сложных запросов, чем поиск всех сущностей или по-иск по id, то было бы полезно, если бы технология позволяла обрабатывать сохраненные в оперативной памяти данные.
На основе этих идей было сформулировано определение IMDG [1] (In-Memory Data Grid, data grid) – это набор географически распределенных компьютеров или сервисов, которые могут взаимодействовать друг с дру-гом и осуществлять координацию большого количества информации. Та-кой подход предполагает хранение данных в оперативной памяти для более
3
быстрого доступа и работы с ними.
Введение | 3 |
Цели и задачи | 5 |
Обзорная часть | 6 |
Обзор внутреннего ORM-фреймворка . . . . . . . . . . . . . . . . | 6 |
IMDG&IMDB............................. | 10 |
IMDG & distributed cache . . . . . . . . . . . . . . . . . . . . . . . | 11 |
Сравнениеаналогов .......................... | 11 |
Практическая часть | 14 |
Конфигурация Hazelcast . . . . . . . . . . . . . . . . . . . . . . . . | 14 |
MapStore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | 14 |
Точки взаимодействия с словарями . . . . . . . . . . . . . . . . . | 14 |
Запросы в data grid . . . . . . . . . . . . . . . . . . . . . . . . . . | 15 |
Замерыпроизводительности . . . . . . . . . . . . . . . . . . . . . | 16 |
Выводы | 20 |
Список литературы | 21 |
2
Введение
С каждым годом становится все больше различной информации равно, как и людей, ответственных за работу с разрастающимися базами данных, их поддержку и улучшение производительности. Но у вертикального улуч-шения производительности существует потолок, после которого добавление новых мощностей дает незначительный эффект – тогда появляется смысл
- горизонтальном расширении.
Можно делать базы данных распределенными, балансировать нагрузку на сервера, доступ к удаленной базе все равно зачастую являются узким местом системы. Поэтому появилось кэширование – сохранение последних запросов или конкретных таблиц в оперативной памяти, чтобы для попу-лярных поисковых запросов и сущностей не обращаться к базе данных. Однако и у кэширования несложно найти недостатки: даже если иметь мощные сервера с большим количеством предзагруженных в кэш данных (что называется ”прогрев”), то по этим данным нельзя строить сложные запросы с фильтрами, потому что обычный кэш не гарантирует хранение всех данных конкретной сущности и что они не успели устареть.
Эта проблема решается паттернами доступа к источникам данных: write-through (запись в промежуточный узел – например, кэш – вызывает ав-томатическую запись в источник данных), write-behind (то же самое, но асинхронно), read-through (если на конкретный запрос не известно, хра-нится сущность или нет, то промежуточное звено обращается к источнику данных и запоминает результат) и другими вендор-специфическими шаб-лонами. Но хранить всю информацию на одном сервере, тем более, в опе-ративной памяти, может стать слишком большой нагрузкой, поэтому важ-на возможность распределять информацию по различным узлам, которые смогут координированно и консистентно ею управлять; и раз есть запрос на обработку более сложных запросов, чем поиск всех сущностей или по-иск по id, то было бы полезно, если бы технология позволяла обрабатывать сохраненные в оперативной памяти данные.
На основе этих идей было сформулировано определение IMDG [1] (In-Memory Data Grid, data grid) – это набор географически распределенных компьютеров или сервисов, которые могут взаимодействовать друг с дру-гом и осуществлять координацию большого количества информации. Та-кой подход предполагает хранение данных в оперативной памяти для более
3
быстрого доступа и работы с ними.
Характеристики курсовой работы
Список файлов
Интеграция Hazelcast в сервер федеративных запросов.doc