Записки программиста, обо всем и ни о чем. Но, наверное, больше профессионального.

2009-09-17

Базы данных в облаках

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

Эта архитектура реализована компанией 28msec в продукте Sausalito. В Sausalito в единую переносимую платформу интегрируются виртуальная машина, система управления данными, процессор потоков данных, система управления очередями и Web-сервер. Это производит впечатление еще одного монстра, даже более ужасного, чем СУБД, но на самом деле это не так. В настоящее время размер всей платформы составляет всего около 140 мегабайт, в основном, за счет того, что она обладает более скудными и целенаправленными функциональными возможностями.

В Sausalito все данные и (откомпилированный) код приложения хранятся в виде BLOB'ов с использованием Amazon S3. Каждый HTTP-запрос (например, инициируемый пользователем из Web-браузера или путем вызова Web-сервиса из некоторого приложения) обрабатывается следующим образом. На основе использования службы Amazon EC2 и ее сервиса планирования и балансировки нагрузки для обработки этого запроса выбирается доступный сервер EC2. Для обработки запроса этот сервер загружает из S3 откомпилированный код. Затем этот код интерпретируется на данном сервере EC2 подсистемой Sausalito поддержки времени выполнения, возможно, производя доступ к объектам базы данных, которые также сохраняется в виде BLOB'ов в S3. Во всех серверах EC2 не сохраняется состояние, и допускается выход из строя каждого из них в любой момент времени. При повышении (уменьшении) нагрузки, число серверов EC2 может быть увеличено (соответственно, сокращено). В Amazon S3 на уровне хранения данных используются дешевые аппаратные средства, и доступность данных достигается путем репликации всех BLOB'ов в нескольких узлах разных центров данных. Синхронизация параллельного доступа к одним и тем же данным (от нескольких серверов EC2) производится на основе использования протоколов, описанных в [3].

В качестве языка программирования для реализации логики приложения и обеспечения доступа к базе данных в Sausalito используется XQuery (с расширениями для обновления данных и применения скриптов). В Sausalito применяется XQuery, потому что в этом языке хорошо поддерживаются все стандарты Web (в частности, стандарты REST и Web-сервисов), имеются развитые средства запросов к базам данных, и возможностей этого языка достаточно для создания развитых Web-приложений. Для тех же целей в AppEngine компании Google используется Python со встраиваемым диалектом SQL для доступа к базам данных. Компания же Microsoft опирается на языки семейства .NET и LINQ.

Очевидно, что у любой системы (включая Sausalito), основанной на архитектуре с рис. 2, мало шансов сравняться с современными системами баз данных в отношении производительности и согласованности данных. Что касается согласованности, то в соответствии с теоремой Бревера (Eric A. Brewer) [7] невозможно одновременно реализовать строгую согласованность, высокую доступность и масштабируемость. Если же говорить о производительности, то современные СУБД оптимизировались для достижения этой цели в течение, фактически, сорока лет. Однако архитектура с рис. 2 хорошо соответствует остальным характеристикам из табл. 1. Как показывает опыт Sausalito, эту архитектуру можно где угодно экономически эффективно реализовать с использованием дешевых аппаратных средств. Кроме того, в этом случае масштабируемость обеспечивается автоматически. Гибкость достигается за счет упрощения платформы, а также использования на всех уровнях одной модели программирования и данных, а не разных моделей на каждом уровне. Как показано в [3], для многих рабочих нагрузок можно добиться предсказуемых расходов и производительности.

Из сказанного в этом разделе должно стать ясно, что архитектура с рис. 2 создавалась в противоположность принципам разработки, свойственным архитектуре с рис. 1. Вместо централизованного контроля всех чтений и записи данных используются соглашения, регулирующие доступ к данным в распределенной, слабо связанной среде. Эти соглашения реализуются как распределенные протоколы [15, 3]. Вместо того чтобы перемещать как можно больше функциональных средств ближе к данным, на уровне хранения поддерживается минимальный интерфейс "get" и "put". Вся остальная функциональность реализуется на прикладном уровне.


citforum.ru/database/articles/rethinking


Сцылки дня:

Комментариев нет:

Отправить комментарий

Архив блога

Ярлыки

linux (241) python (191) citation (186) web-develop (170) gov.ru (159) video (124) бытовуха (115) sysadm (100) GIS (97) Zope(Plone) (88) бурчалки (84) Book (83) programming (82) грабли (77) Fun (76) development (73) windsurfing (72) Microsoft (64) hiload (62) internet provider (57) opensource (57) security (57) опыт (55) movie (52) Wisdom (51) ML (47) driving (45) hardware (45) language (45) money (42) JS (41) curse (40) bigdata (39) DBMS (38) ArcGIS (34) history (31) PDA (30) howto (30) holyday (29) Google (27) Oracle (27) tourism (27) virtbox (27) health (26) vacation (24) AI (23) Autodesk (23) SQL (23) humor (23) Java (22) knowledge (22) translate (20) CSS (19) cheatsheet (19) hack (19) Apache (16) Klaipeda (15) Manager (15) web-browser (15) Никонов (15) functional programming (14) happiness (14) music (14) todo (14) PHP (13) course (13) scala (13) weapon (13) HTTP. Apache (12) SSH (12) frameworks (12) hero (12) im (12) settings (12) HTML (11) SciTE (11) USA (11) crypto (11) game (11) map (11) HTTPD (9) ODF (9) Photo (9) купи/продай (9) benchmark (8) documentation (8) 3D (7) CS (7) DNS (7) NoSQL (7) cloud (7) django (7) gun (7) matroska (7) telephony (7) Microsoft Office (6) VCS (6) bluetooth (6) pidgin (6) proxy (6) Donald Knuth (5) ETL (5) NVIDIA (5) Palanga (5) REST (5) bash (5) flash (5) keyboard (5) price (5) samba (5) CGI (4) LISP (4) RoR (4) cache (4) car (4) display (4) holywar (4) nginx (4) pistol (4) spark (4) xml (4) Лебедев (4) IDE (3) IE8 (3) J2EE (3) NTFS (3) RDP (3) holiday (3) mount (3) Гоблин (3) кухня (3) урюк (3) AMQP (2) ERP (2) IE7 (2) NAS (2) Naudoc (2) PDF (2) address (2) air (2) british (2) coffee (2) fitness (2) font (2) ftp (2) fuckup (2) messaging (2) notify (2) sharepoint (2) ssl/tls (2) stardict (2) tests (2) tunnel (2) udev (2) APT (1) Baltic (1) CRUD (1) Canyonlands (1) Cyprus (1) DVDShrink (1) Jabber (1) K9Copy (1) Matlab (1) Portugal (1) VBA (1) WD My Book (1) autoit (1) bike (1) cannabis (1) chat (1) concurrent (1) dbf (1) ext4 (1) idioten (1) join (1) krusader (1) license (1) life (1) migration (1) mindmap (1) navitel (1) pneumatic weapon (1) quiz (1) regexp (1) robot (1) science (1) seaside (1) serialization (1) shore (1) spatial (1) tie (1) vim (1) Науру (1) крысы (1) налоги (1) пианино (1)