Большинство .NET разработчиков очень редко задаются вопросом где и как хранить данные приложения. Прекрасная интеграция SQL Server с .NET делает его универсальным и удобным хранилищем, которое мы, не задумываясь, используем в любых задачах. Современные СУБД – это замечательный пример слияния прекрасных инженерных решений и десятков лет опыта в создании надежных, оптимизированных хранилищ данных. Однако все больше программистов выбирают NoSQL хранилища данных, что последнее время считается модным и прогрессивным. Недавно я решил изучить возможности NoSQL и удобство работы с ними в .NET, и в этой статье поделюсь с вами своим опытом и впечатлениями.Если немного вернуться в прошлое, 2009 год я бы назвал годом ORM систем. Такие движки как Linq to SQL, Entity Framework, NHibernate стали обязательными инструментами в боекомплекте любого .NET разработчика. В году нынешнем все чаще можно услышать восторженные отзывы о MongoDb, CouchDB, Cassandra и других хранилищах, а «select fun, profit from real_world where relational=false;» - новый лозунг веб-программистов на динамических языках. NoSQL-хранилища, или document-oriented storages, плотно закрепились на рынке и завоевывают все большую популярность. К тому же, пример подают такие гиганты как Amazon (Dynamo), Google (BigTable), Twitter (Cassandra) и многие другие.
Чем же не устраивают реляционные СУБД?Многие проекты имеют высокую динамичность данных. Сущности системы часто меняют структуру, похожие сущности могут немного отличаться набором данных, а некоторые из уже существующих могут со временем «обрастать» новыми свойствами. Из-за строгой структуры данных в базе любые изменения схемы сущностей нужно отражать в структуре таблиц, постоянно усложняя модель (например, в случае наследования) и готовя migration-скрипты. При этих изменениях необходимо менять SQL-запросы или маппинг объектов, к тому же скорость доступа к данным может существенно пострадать (вспомним запросы, генерируемые Entity Framework при Table-per-Type наследовании). В итоге – нам необходимо поддерживать две разнородные модели – реляционную в базе и объектную в коде, и зачастую страдать от потерь производительности. Также, многие проекты не требуют строгой поддержки ACID-принципов. Намного важнее представляется быстрая обработка данных с минимальным временем отклика, а также быстрая и простая горизонтальная масштабируемость. Кроме того, иногда объем обрабатываемых данных настолько велик, что единственным возможным путем работы является параллельное её решение на кластере.
Концепция NoSQL-хранилищПопробую перечислить наиболее характерные, на мой взгляд, особенности:Schema-less данные. Вместо строго структурированных таблиц мы и имеем коллекции документов, а в некоторых системах и просто наборы ключ-значение. Структура каждого документа может быть индивидуальной, фактически он сам себя описывает. Поддержка документов разной структуры ложится на плечи логики приложения. Read more: dev.net.ua
Чем же не устраивают реляционные СУБД?Многие проекты имеют высокую динамичность данных. Сущности системы часто меняют структуру, похожие сущности могут немного отличаться набором данных, а некоторые из уже существующих могут со временем «обрастать» новыми свойствами. Из-за строгой структуры данных в базе любые изменения схемы сущностей нужно отражать в структуре таблиц, постоянно усложняя модель (например, в случае наследования) и готовя migration-скрипты. При этих изменениях необходимо менять SQL-запросы или маппинг объектов, к тому же скорость доступа к данным может существенно пострадать (вспомним запросы, генерируемые Entity Framework при Table-per-Type наследовании). В итоге – нам необходимо поддерживать две разнородные модели – реляционную в базе и объектную в коде, и зачастую страдать от потерь производительности. Также, многие проекты не требуют строгой поддержки ACID-принципов. Намного важнее представляется быстрая обработка данных с минимальным временем отклика, а также быстрая и простая горизонтальная масштабируемость. Кроме того, иногда объем обрабатываемых данных настолько велик, что единственным возможным путем работы является параллельное её решение на кластере.
Концепция NoSQL-хранилищПопробую перечислить наиболее характерные, на мой взгляд, особенности:Schema-less данные. Вместо строго структурированных таблиц мы и имеем коллекции документов, а в некоторых системах и просто наборы ключ-значение. Структура каждого документа может быть индивидуальной, фактически он сам себя описывает. Поддержка документов разной структуры ложится на плечи логики приложения. Read more: dev.net.ua
Posts
0 comments:
Post a Comment