MS Access (MDB) параллелизм

Question

Для небольшого проекта мне нужно использовать простую базу данных с очень легкими требованиями: несколько таблиц, всего не более нескольких тысяч записей, 2 или 3 пользователя. Я работаю в среде .NET.

Поскольку сервер базы данных (даже эти выпуски Express) в этом случае выглядит огромным перебором, очень простая база данных MDB может удовлетворить большинство требований. Я, однако, обеспокоен параллелизмом. Моя идея состоит в том, чтобы поместить файл .mdb в общую сетевую папку и позволить пользователям получать доступ к этому файлу со своих клиентов на основе .NET. БД в основном предназначена для операций только для чтения, но пользователям иногда также необходимо обновлять / удалять записи. Если это будет невозможно в то время (из-за блокировки БД или чего-то еще), я могу задержать обновления на клиенте и обработать их позже.

Сам вопрос звучит так:

• Как обрабатываются параллельные чтения в MDB?
• Как обрабатываются одновременные обновления / удаления в MDB?
• Существует ли концепция блокировок и как ее использовать в приложении .NET?
• Является ли размещение файла MDB на сетевом ресурсе хорошей или ужасной идеей?

Поскольку я работаю в .NET, мне также хотелось бы знать, как я могу обнаружить любые проблемы с параллелизмом и предпринять соответствующие действия. То есть, какое исключение я должен поймать и какие действия вы бы порекомендовали предпринять?

РЕДАКТИРОВАТЬ : Это может быть моим плохим описанием проблемы, но большинство ответов, кажется, советуют использовать полноценный сервер БД. Я понимаю различия и преимущества установки сервера и фактически реализовал значительное количество проектов на MSSQL и Oracle. В этом вопросе, однако, я касаюсь только доступа и его проблем параллелизма, поэтому, пожалуйста, не предлагайте db-сервер.

Спасибо за вашу помощь.

Answer 1

Это старый вопрос, но никто так и не ответил на него. Вот вопросы:

1. Как обрабатываются параллельные чтения в MDB?
2. Как обрабатываются параллельные обновления / удаления в MDB?
3. Существует ли концепция блокировок и как ее использовать в приложении .NET?
4. Является ли размещение файла MDB на сетевом ресурсе хорошей или ужасной идеей?

На первые два вопроса можно ответить одним объяснением. Одно ключевое предостережение: ответы, которые я даю здесь, относятся к Jet MDB (и их вариантам) и не полностью применимы к новому формату файлов, введенному начиная с A2007, то есть к формату ACCDB. Я не полностью изучил последствия удаления Jet ULS из ACE, и некоторые из комментариев ниже могут предполагать, что Jet ULS находится под капотом. Однако для многих вещей вы можете заменить "LACCDB file" на "LDB file", и результаты будут такими же.

1-2) Одновременное чтение / обновление / удаление

Ядро базы данных Jet часто называют базой данных «файлового сервера», поскольку на сервере нет демона на стороне сервера, управляющего вводом / выводом с помощью файлов данных. Это означает, что все клиенты, использующие Jet MDB, читают файл напрямую.

Это, конечно, рецепт катастрофы, если нет встроенного механизма для обработки одновременного доступа к файлу.

Jet использует файл блокировки записи, где, если ваш MDB - «MyFile.MDB», файл блокировки записи будет находиться в той же папке и называется «MyFile.LDB». Файл LDB записывает, что пользователи Jet ULS имеют открытый файл MDB, с какой рабочей станции подключен этот пользователь, и всю информацию, необходимую для согласования проблем параллелизма.

Теперь, для тех, кто режет зубы на ядро ​​клиент-серверной базы данных, это может показаться примитивным и опасным, но в то время, когда ядро ​​базы данных Jet разрабатывалось, его целью было использовать его в качестве движка базы данных для настольных компьютеров для небольших рабочих групп. и он конкурировал с другими настольными механизмами БД, такими как xBase и Paradox, которые использовали аналогичные блокирующие файлы для управления одновременным использованием файлов данных от нескольких клиентов.

В файле базы данных Jet блокировки применяются либо к страницам данных (которые в Jet 4 были увеличены до 4 КБ, тогда как в Jet 3.x и ранее они были 2 КБ), либо на уровне записи, если таблица данных была изначально создан для использования блокировки на уровне записей. В первые дни Jet 4 многие находили блокировку на уровне записи довольно медленной, особенно при использовании пессимистической блокировки, поэтому многие разработчики Access никогда не использовали ничего, кроме блокировки на уровне страниц (@David Fenton поднимает руку!).

Фактически, при использовании оптимистической блокировки вы избегаете большинства проблем параллелизма, которые могут возникнуть при пессимистической блокировке.

Некоторые предостережения:

1. от DAO, блокировка на уровне записи недоступна, и вы только когда-либо получаете блокировку на уровне страницы.

2. из DAO, есть ряд опций для управления оптимистической / пессимистической блокировкой, в частности аргумент LockEdits метода OpenRecordset, но он также взаимодействует с некоторыми настройками, указанными в аргументе параметров OpenRecordset Options (например, Опция dbReadOnly не может использоваться с LockEdits). В дополнение к блокировке, есть также варианты для согласованных / противоречивых обновлений, и все это может взаимодействовать с транзакциями (например, изменения в несвязанной транзакции не будут видны другим пользователям и, следовательно, не будут конфликтовать с ними, но это может устанавливать блокировки только для чтения на соответствующие таблицы).

Из ADO / OLEDB эти структуры управления параллелизмом Jet будут отображаться на соответствующие функции и аргументы, найденные в ADO / OLEDB. Поскольку я использую Jet только из Access, я взаимодействую с ним только через DAO, поэтому я не могу посоветовать, как вы управляете ими с помощью ADO / OLEDB, но дело в том, что ядро ​​базы данных Jet обеспечивает контроль блокировки вашей записи при доступе к ней. программно (в отличие от интерфейса доступа) - это просто сложнее.

3) Замки и .NET

Я не могу дать здесь никакого совета, кроме того, что вы, скорее всего, будете использовать OLEDB в качестве интерфейса данных, но дело в том, что функции блокировки / управления есть в самом движке db, так что, вероятно, есть способ контролировать это через OLEDB. Впрочем, это может быть не очень красиво, так как мне кажется, что OLEDB спроектирован на основе клиент-серверных архитектур, и файловая блокировка Jet может не отображаться на этом элегантным способом.

4) MDB на сетевом ресурсе

Jet очень чувствителен к малейшим сбоям в любом сетевом соединении. Из-за этого сети с низкой пропускной способностью могут увеличить уязвимость баз данных Jet, открытых через медленное соединение.

Это связано с тем, что основные фрагменты файла базы данных должны быть переданы по проводам в оперативную память локального компьютера для обработки. Теперь многие люди ошибочно утверждают, что весь файл MDB протягивается по проводам или что целые таблицы протягиваются по проводам. Это неправда. Вместо этого Jet сначала запрашивает индексы (и запрашивает не больше, чем необходимо для выполнения запроса), а затем на основании этого результата точно определяет, какие страницы данных необходимы, а затем извлекает только эти страницы. Это удивительно эффективно и быстро.

Кроме того, Jet выполняет очень интеллектуальное кэширование, которое может означать, что первый запрос данных может занять некоторое время, но последующие запросы на те же данные происходят почти мгновенно из-за кэширования.

Теперь, если вы недостаточно хорошо проиндексировали свои таблицы, вы можете закончить тем, что потянете всю таблицу и выполните полное сканирование таблицы. Аналогично, если вы основываете критерии на клиентских функциях, которые не являются частью диалекта SQL Jet, вы можете в конечном итоге получить полную таблицу (сортировка, скажем, по Replace (MyField, "A", "Z") может вызвать полное сканирование таблицы). Но такого рода вещи будут неэффективными и с архитектурой клиент / сервер, поэтому достаточно просто спроектировать схему, чтобы правильно индексировать объекты и быть осторожными с использованием UDF или не-совместимых функций. В общем, те же самые вещи, которые эффективны с клиентом / сервером, будут эффективны и с Jet (главное отличие в том, что с Jet вы будете лучше иметь постоянное соединение, чтобы избежать накладных расходов при воссоздании файла LDB, что является значительным).

Другая вещь, которую следует избегать, - это попытаться использовать данные Jet через соединение WiFi. Мы все знаем, насколько ненадежен WiFi, и он просто пытается решить проблему с данными Jet через соединение WiFi.

Суть:

Если вы используете MDB в качестве хранилища данных для обслуживания данных с веб-сервера, вы должны поместить данные как можно ближе к оперативной памяти веб-сервера. Это означает, что, по возможности, на томе диска, который подключен к физическому веб-серверу. Там, где это невозможно, вам нужно быстрое и надежное подключение к локальной сети. Локальные сети GB в центрах обработки данных довольно распространены в наши дни, и мне было бы очень удобно работать с данными Jet через такое соединение.

Для совместного использования, например, нескольких клиентских рабочих станций, на которых запущено настольное приложение VB.NET, совместно использующих один MDB-накопитель Jet в качестве хранилища данных, достаточно безопасно хранить файл данных на надежном файловом сервере. Там, где это возможно, рекомендуется размещать файлы Jet MDB на компьютерах, которые не предназначены для нескольких целей (например, контроллер домена, на котором работает Exchange, SQL Server и который выступает в качестве файлового сервера и сервера печати, может оказаться не лучшим местом) , Такие приложения, как Exchange, могут сильно мешать работе файлового сервера, и я, как правило, рекомендую никогда не размещать файлы MDB на многозадачном сервере в качестве сервера Exchange, если только его объем не слишком мал.

Другие соображения:

1. никогда не пытайтесь распространять MDB в реплицированной файловой системе, если только все пользователи не используют одну и ту же реплику. То есть, если у вас есть два сервера, реплицирующие файлы между ними, даже не думайте о редактировании файла MDB с обоих серверов. Это почти сразу повредит файл.

2. Я бы не рекомендовал хранить какие-либо MDB-файлы на чем-либо, кроме собственной файловой системы Windows, обслуживаемой через собственные сети Microsoft SMB. Это означает, что нет Novell, нет Linux, нет SAMBA. Ключевая причина этого заключается в том, что, очевидно, существуют низкоуровневые хуки от Jet для некоторых низкоуровневых блокировок в файловой системе Windows, которые не реплицируются на 100% на другие файловые системы. Теперь я очень консервативен в этом вопросе, и многие компетентные разработчики Access сообщили о превосходных результатах с правильно настроенными файловыми серверами Novell (часто необходимо внести некоторые коррективы в блокировку записи, хотя в наши дни это может быть менее актуально - я не понимаю даже не знаю, существует ли Novell больше!), и невероятная производительность на файловых серверах на базе Linux, работающих под управлением SAMBA. Я осторожен в этом и рекомендую любой клиент против него (в том числе различные устройства SAN, поскольку не многие из них основаны на Windows).

3. Я бы никогда не запустил их в какой-либо виртуализированной файловой системе по тем же причинам. Однако у меня есть клиент, который уже несколько лет запускает свое однопользовательское приложение Access под Parallels на Mac Air без единой проблемы. Но он однопользовательский, поэтому проблемы с блокировками будут относительно незначительными.

Я не знаю, отвечает ли это на ваши вопросы или нет. Все это основано на моем 13-летнем регулярном использовании Jet в качестве разработчика Access и изучении единственной опубликованной книги по Jet, Руководства для программистов Jet Database Engine (только для Jet 3.5). Я не предоставил никаких реальных ссылок, но если кому-то понадобятся какие-то подробности по поводу того, что я сказал, я проведу исследование, если смогу.

Answer 2

За последние годы я создал около десятка приложений для малого бизнеса в Access. Большинство из них имеют максимум 10-20 пользователей одновременно. Базы данных разделены между базой данных «приложение» и «данные». Производительность приличная и нет проблем с параллелизмом. Кроме того, коррупция практически не существует со времен Access 2000 SP2.

Многие люди говорят: «Никогда не пользуйтесь Access» - хорошо, если все сделано правильно (например, профессиональным разработчиком). Access - прекрасный пакет для разработки, и я неплохо с этим справился. Мои клиенты очень довольны тем, что я построил.

Answer 3

Я написал два коммерческих продукта, в которых используется база данных Access, работающая с общего сетевого ресурса, обычно для 10 пользователей. Если вы не злоупотребляете этим, проблем нет; но, как вы можете видеть, многие разработчики никогда не добираются туда - и из-за его низкого уровня, на нем построено много дурацких хаков. В случае с одним продуктом мне пришлось перепроектировать приложение из-за всех проблем, подробно описанных другими; но после того, как я его очистил, у меня никогда не возникало проблем с целостностью базы данных в сотнях установок.

Одним из его больших преимуществ является единая файловая база данных, которую легко создавать резервные копии, восстанавливать и копировать на ноутбук для анализа. Практически все альтернативы, включая sqlite (хотя некоторые этого не признают), время от времени требуют некоторого внимания со стороны администратора баз данных.

В большинстве случаев Access по умолчанию обеспечивает блокировки записей и файлов для некоторых DDL (например, изменений схемы).

Но Microsoft в основном устарела, и некоторые из ваших коллег будут насмехаться над вами за его использование.

(В этот момент я обычно прячусь за укрытие и кричу «ВХОДЯЩИЙ !!!».)

Answer 4

Access - это действительно настольное однопользовательское решение. На практике верхний предел пользователя равен «один».

Это также местный двигатель. То есть, когда вы запускаете запрос, данные передаются по сети на локальный механизм JET для обработки. Файл .ldb помещается в общий сетевой ресурс для управления блокировками.

Если вы используете серверный механизм (MSSQL, MySQL, Sybase, 'Orable и т. Д.), То вы отправляете запрос механизму, который его обрабатывает и возвращает результаты вам. Замки удерживаются внутри.

Это имеет огромное значение для производительности, стабильности и целостности данных.

Если ваш пользователь решит нажать кнопку сброса, у базы данных Access есть большая вероятность быть поврежденной, и вам придется удалить файл .ldb.

С надлежащим механизмом базы данных (MSSQL, Sybase, 'Orable: мне не нравятся резервные копии MySQL), тогда у вас также есть надлежащая возможность резервного копирования. Если у вас нет программного обеспечения для резервного копирования неиспользуемых файлов, возможно, у вас не будет резервных копий ваших данных в базе данных Access.

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

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

Answer 5

Я использовал Access или, точнее, Jet в качестве бэк-энда на очень маленьком частном сайте, который никогда не сможет расти, поскольку он ограничен размером профессии в этой маленькой стране. За три года у меня не было никаких проблем. Существует менее 100 пользователей, каждый день их используют от тридцати до сорока человек. Таблицы имеют несколько тысяч записей.

Answer 6

Доступ должен быть многопользовательским - я думаю, что Microsoft рекомендует его для 4 или 5 пользователей, но на практике я бы рекомендовал вам никогда не использовать базу данных Access, если в ней более одного пользователя, хотя если у вас действительно нет выбора, приемлемого для двоих или троих, при определенных условиях.

Я имел опыт работы с четырьмя или пятью системами, использующими серверную часть базы данных Access - все это приобретено у других «разработчиков», и во всех случаях я перемещал их на SQL Server в качестве приоритета после любых немедленных обновлений. и исправления, требуемые при принятии контракта - как правило, как только я мог говорить боссу, оплачивающему счет в это. Промежуток времени для этого обычно составляет несколько месяцев, поэтому я видел, что он работает параллельно в течение разумного периода времени в нескольких различных приложениях.

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

1. Он подвержен коррупции - он просто делает. Как правило, это не слишком большая проблема, так как открытие файла и запуск сжатия и восстановления позволят решить проблемы, но хороший режим резервного копирования абсолютно необходим.

2. Это медленно. Каждый раз, когда я обновлял систему до SQL Server, я получал много благодарностей за ускорение работы системы от пользователей.

3. Файл базы данных раздувается из-за способа, которым Access отмечает записи как обновленные или удаленные. Это еще больше замедляет работу системы, поскольку файл должен быть загружен по сети. Следовательно, необходим некоторый режим, который сжимает данные, обычно на ежедневной основе.

Все вышеперечисленное является гораздо меньшей проблемой для однопользовательских систем, поскольку основные проблемы, вызывающие их, гораздо менее заметны.

В общем, я должен подчеркнуть, что я никогда не рекомендовал бы Access для любой многопользовательской системы. Однако, если это действительно так, вам, вероятно, это сойдет с рук, если это малоиспользуемое приложение и вы внедрили процедуры резервного копирования и обслуживания.

Answer 7

У меня нет большого опыта работы с Access, но эта ссылка может быть вам полезна:

http://office.microsoft.com/en-us/access/HP052408601033.aspx

"Вы можете разместить всю базу данных Access на сетевом сервере или в общей папке. Это самый простой способ для реализации. Каждый разделяет данные и использует одни и те же формы, отчеты, запросы, макросы и модули. Используйте это стратегии, если вы хотите, чтобы все использовали базу данных Access одинаково, или если вы не можете поддержать пользователей, создающих свои собственные объекты. "

"При открытии файла базы данных Access (.mdb) в режиме общего доступа Microsoft Access также создает файл информации о блокировке (.ldb) с тем же именем файла (например, Northwind.ldb) и в той же папке, что и файл базы данных. Этот файл информации о блокировке хранит имя компьютера (например, mypc) и имя безопасности (например, Admin) каждого общего пользователя базы данных. Microsoft Access использует эту информацию для управления параллелизмом. В большинстве случаев Microsoft Access автоматически удаляет файл информации о блокировке, когда последний пользователь закрывает файл базы данных. "

Answer 8

Уже несколько раз говорилось об использовании реальной многопользовательской бесплатной платформы баз данных. Но одна из причин, почему не было заявлено. Причина в том, сколько существующих, грязных, хлопотных, больших баз данных Access начиналось как «несколько записей, максимум один или два пользователя»? Я рискну сказать все из них.

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

Answer 9

Я думаю, вы можете определить это в строке подключения вашего приложения .net. Я гуглил по JET, доступу и блокировке записи

вот ссылка , которая может помочь.

Пожалуйста, ознакомьтесь с принятым ответом для реальной информации о том, как Access и JET получают данные.

Answer 10

При работе с сетевым ресурсом вместо доступа я бы использовал базу данных с поддержкой сети (mysql / firebird / mssql).

Для ситуации, которую вы описываете с помощью Access, проблем не будет.

Я использовал Access в более сложных ситуациях, чем в основном при работе с веб-сайтами, когда Access не подвергался чрезмерному злоупотреблению, на самом деле это не так уж плохо для движка базы данных. (не говоря о формах и подобных вещах, просто таблицах и записях)

Когда вы выполняете операции вставки / обновления / удаления от нескольких пользователей одновременно, это становится немного странным. Это тот момент, когда вы начинаете думать о реальных движках баз данных.

Также, если вам нужна база данных с низкими издержками, которая является поточно-ориентированной, вы можете взглянуть на vistadb (медленнее, чем доступ, не всегда бесплатный, 100% .NET)

Я думаю, что доступ использует блокировки на уровне таблицы с каким-то механизмом запросов, все должно работать нормально. Если вы беспокоитесь об этом, вы всегда можете провести симуляцию стресс-теста.