Скорость файловой системы против базы данных для частой обработки данных

Question

Мне нужно передать данные в службу обработки данных Windows (односторонняя, слабосвязанная). Я хочу убедиться, что служба не работает и т. Д. Не приводит к «потере» данных, что перезапуск службы Windows просто заставляет ее выполнять работу там, где она оставлена, и мне нужно, чтобы система была действительно простой для устранения неполадок, поэтому я не использую MSMQ.

Итак, я придумал одно из двух решений - либо:

• Я перетаскиваю текстовые файлы с данными обработки в каталог для перетаскивания, и служба Windows ожидает уведомлений об изменении файла, обрабатывает и удаляет файл, а затем

или

• Я вставляю данные в специальную таблицу в локальной базе данных MS SQL, и служба Windows опрашивает базу данных на предмет изменений / новых элементов, а затем стирает их по мере их обработки

База данных MSSQL локальная в системе, а не по сети, но позже я могу захотеть перенести ее на другой сервер.

Что, с точки зрения производительности (или другой точки зрения), является лучшим решением здесь?

Answer 1

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

Однако есть и другие факторы, которые следует учитывать.

• Неважно, насколько он быстрый, как правило, только в том случае, если он достаточно быстрый. Хранение и извлечение мелких капель - это простая задача, и вполне возможно, что это никогда не станет вашим узким местом.
• NTFS записывается в журнал - но только метаданные. Если в середине записи произошел сбой сервера, файл может содержать бред. Если вы используете бэкэнд файловой системы, вам нужно быть устойчивым к произвольным данным в файлах. В зависимости от уровня кэширования и способа, которым файловая система повторно использует старое пространство, этот тарабарщина может содержать сегменты других сообщений, поэтому вам лучше всего противостоять повторению старого сообщения.
• Если вы когда-нибудь захотите добавить новые функции, включающие более богатую модель сообщений, база данных будет легче расширяться (скажем, некоторый уровень кэширования).
• Файловая система более «открыта» - это означает, что ее можно будет легче отлаживать с помощью действительно простых инструментов (блокнот), но также вы можете столкнуться с более сложными проблемами с локальными службами индексирования, антивирусными сканерами, плохо установленными разрешениями или чем-то еще случается жить в системе.
• Большинство API не могут работать с файлами с путями длиной более 260 символов и плохо работают при работе с огромным количеством файлов. Если ваш каталог хранения станет слишком большим, такие вещи, как .GetFiles(), станут медленными - тогда как БД может быть проиндексирована по временной метке, а самые новые сообщения будут извлечены независимо от старого беспорядка. Вы можете обойти это, но это дополнительное препятствие.
• MS SQL не бесплатен и / или не установлен в каждой системе. Для каждого нового сервера требуется немного дополнительного системного администрирования и больше патчей при его использовании. В частности, если ваша программа должна быть легко установлена ​​третьими лицами, у файловой системы есть преимущество.

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

Answer 2

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

Тем не менее
Новый SQL-сервер 2008 имеет улучшенную поддержку файлов в движке.