Какие аргументы следует использовать, чтобы объяснить, почему SQL Server намного лучше, чем плоский файл

В моих компаниях лучшие друзья говорят, что плоские файлы - это путь, и мы должны переключиться с SQL Server на них для всего, что мы делаем. У нас более 300 серверов и сотни различных баз данных. Из тех немногих, с кем я связан, у нас есть > 10 миллиардов записей в довольно многих из них с более чем 100k новых записей в день и кто знает, сколько обновлений... Мне и парам других нужно придумать ответ говоря, почему мы не должны этого делать. Большая часть нашего материала - ASP.NET с некоторым устаревшим ASP. Мы думали, что создание простого консольного приложения, которое проверяет/разывает те же самые взаимодействия между плоским файлом (хранящимся в сети) и SQL по сети, делая большие вставки, поиски, обновления и т.д. Вместе со случайными сетевыми отключениями. Это покажет им, насколько плохими могут быть плоские файлы, особенно когда вы имеете дело с миллионами записей.

Что я должен использовать в своем ответе? Что мне делать с демо-кодом, чтобы проиллюстрировать это?

Мой список сортировки:

  • Безопасность
  • Параллельный доступ
  • Производительность с большими объемами данных
  • Количество времени для такого массового переписывания/переключения и огромной стоимости
  • Отсутствие транзакций
  • PITA для сопоставления реляционных данных с плоскими файлами
  • NTFS не поддерживает тонны файлов в каталоге.
  • Отсутствие поиска/манипулирования данными Adhoc
  • Обеспечение целостности данных
  • Восстановление после сбоя сети.
  • Задержка клиента в ожидании изменений других клиентов для фиксации
  • Большинство пользователей давно перестали использовать плоские файлы для этого типа хранилища.
  • Балансировка/репликация нагрузки

Я боюсь, что это будет отличный пост в Daily WTF когда-нибудь, если я не могу остановить его сейчас.

Дополнительно

Кто-нибудь знает, может ли что-нибудь о HIPPA быть использовано в этом бою? Многие из наших записей - это записи пациентов...

Ответ 1

  • Целостность данных. Во-первых, вы можете принудительно применять его в базе данных и не можете в плоском файле. Во-вторых, вы можете убедиться, что у вас есть ссылочная целостность между различными объектами, чтобы предотвратить сиротство строк.

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

  • Возможности собственных запросов. Вы можете запросить базу данных изначально, тогда как вы не можете с плоским файлом. С плоским файлом вы должны загрузить файл в другую среду (например, приложение С#) и использовать его возможности для запроса на него.

  • Отформатируйте целостность. Формат базы данных более жесткий, что означает более последовательное. Плоский файл может легко изменяться таким образом, что код, который читает плоский файл (ы), сломается. Разница связана с №3. В базе данных, если схема изменяется, вы можете запросить ее, используя собственные инструменты. Если формат плоского файла изменяется, вы должны эффективно выполнять поиск, потому что код, который его читает, скорее всего, будет нарушен.

  • "Универсальный" язык. SQL является несколько повсеместным, когда структура плоского файла намного более податлива.

Ответ 2

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

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

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

Ответ 3

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

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

  • Индексация
  • Обработка транзакций
  • Вход
  • Контроль доступа
  • Производительность
  • Безопасность

Ответ 4

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

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

Ответ 5

Если вы используете "текстовые файлы", вам нужно будет создать интерфейс поверх него, который Microsoft уже сделал для вас и назвал его SQL Server.

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

  • Производительность: SQL Server создан для хранения удобных для поиска данных. Он оптимизировал структуры данных в памяти, созданной с помощью поиска/вставки/удаления. Использование диска снижается, поскольку данные, регулярно запрашиваемые, хранятся в памяти.

  • Бизнес-партнеры: если вы когда-либо планируете делать B2B с сторонними компаниями, у SQL Server есть встроенные функции, называемые Linked Servers. Если у вас есть только куча файлов, ваш бизнес-партнер откажется от вас, поскольку соединение данных не будет возможным. Если вы не хотите снова изобретать колесо и создать интерфейс для каждого вашего делового партнера.

  • Кластеризация: вы можете легко кластерные серверы в SQL Server для высокой доступности и скорости, намного больше, чем возможно с помощью текстового решения.

Ответ 6

У вас прекрасное начало в вашем списке. Элементы, которые я добавил бы, включают:

  • Целостность данных. Механизмы SQL предоставляют встроенные механизмы (отношения, ограничения, триггеры и т.д.), которые очень упрощают уменьшение количества "плохих" данных в вашей системе. При использовании плоских файлов вам нужно будет вручную передать все ограничения данных.
  • Add-Hoc data retrieval - SQL-механизмы с помощью операторов SELECT обеспечивают средство фильтрации и суммирования ваших данных с очень маленьким кодом. Если вы используете плоские файлы, для получения одинаковых результатов требуется значительно больше кода.

Эти элементы могут быть реплицированы, если вы хотите потратить время на создание механизма обработки данных, но какой смысл? Механизмы SQL уже предоставляют эти преимущества.

Ответ 7

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

  • Имитировать отключение сети и показать, что происходит с одним из файлов в этой точке.
  • Продемонстрируйте ужасы полуобработанной транзакции, потому что текстовые файлы не проходят тест ACID
  • Если это многопользовательское приложение, покажите, как долго клиент должен ждать, когда все 500 подключений будут пытаться обновить один и тот же текстовый файл.
  • Попытайтесь вежливо объяснить, почему лучший подход к принятию бизнес-решений - это слушать профессионалов, которым вы платите деньги, и кто знает домен (в данном случае, ИТ), а не ваш приятель, у которого нет подсказки ( возможно, оставить этот последний бит)
  • Упомяните тот факт, что 99% (составленный номер) бизнес-мира использует реляционные базы данных для своих важных данных, а не текстовых файлов, и, вероятно, причина для этого
  • Покажите, что происходит с вашим приложением, когда кто-то входит в текстовый файл и вводит его в "ха-ха!". для столбца, который должен быть целым числом

Ответ 8

Ваш список - отличное начало для привязки к базе данных.

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

Вот мои 2 очка против хранения файлов с плоскими файлами:

1) Безопасность - Аудиты HIPPA требуют, чтобы данные пациента оставались в безопасной среде. Общие системы баз данных (Oracle, Microsoft SQL, MySQL) имеют методы для обеспечения доступа к безопасности, совместимого с HIPPA. Сделать это на плоском файле было бы сложно, в лучшем случае.

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

2) Отчетность. Отчетность из любой структурированной системы баз данных проста и распространена. Есть сотни тысяч разработчиков, которые могут выполнять эту задачу. Для отчетов из плоских файлов потребуется разработчик с более высоким уровнем. И поскольку нет общепринятого метода для отчетности о плоской базе данных, один разработчик может делать что-то другое, чем другое. Это может повлиять на пул талантов, способный работать на домашней плоской файловой системе, и в конечном итоге снизить затраты, поддерживая этот тип системы.

Я надеюсь, что это поможет.

Ответ 9

Если вы являетесь публичной компанией, акционерам будет хорошо известно, что это серьезно рассматривается. "Мы" все знаем, что это смехотворное предложение, учитывая размер и объем вашей операции. Записи пациентов должны быть защищены не только от нарушений безопасности, но и от безответственного воздействия на потерю - жизнь может зависеть от данных. Если руководители вообще заботятся о пациентах, ЭТО должно быть их наивысшей заботой.

Я работал с мэйнфреймами IBM 370 с '74 года и в тот день, когда DB2 взяла на себя старые простые плоские файлы, VSAM и ISAM были знаковым днем. Не смотрел назад в хранилище плоских файлов, за исключением потоковых данных, за 25 лет с РСУБД из 4-х ароматов.

Если бы я владел акциями в "тебе", то сбрасывая его в спешке в момент, когда проект взлетел, казалось бы подходящим...

Ответ 10

Как вы создаете реляционную модель с текстовыми файлами?

Или вы планируете использовать другой файл для каждого объекта?

Ответ 11

Профессиональная файловая система:

  • Стабильный (меньше строк кода = меньше ошибок, легче понять, более надежно)
  • Быстрее с огромными каплями данных
  • Поиск/сортировка несколько медленный (но sort может быть быстрее, чем SQL order by)

Итак, вы выбрали файловую систему для создания файлов журналов, например. Вход в БД бесполезен, если вам не нужен комплексный анализ данных.

Pro DB:

  1. Транзакции (включая одновременный доступ)
  2. Он может выполнять поиск через огромное количество записей (но не через огромные капли данных).
  3. Обрезать данные различными способами с запросами легко (ну, если вы знаете свой SQL и специальные "странности" вашей БД)

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

Ответ 12

NTFS не поддерживает массовое количество TXT файлов. В зависимости от того, как развивается плоская файловая система, здоровье жесткого диска может стать проблемой. Многие старые файловые системы используют массовое количество небольших файлов .txt для хранения данных. Это плохой дизайн, но, как правило, происходит, когда плоская файловая система становится старше.

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

Ответ 13

Это действительно со стороны вашего работодателя MAJOR WTF, если он всерьез предлагает плоские файлы для всего...

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

Прежде всего, я напишу script в любом инструменте, который вы сейчас используете для выполнения базовой операции с использованием SQL, и приурочен к ней. Затем я напишу еще один script, в котором вы искренне пытаетесь получить плоское текстовое решение, а затем выделите разницу в производительности. Дайте ему оба набора кода, чтобы он знал, что вы не обманываете.

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

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

Тогда я задал бы серьезные вопросы управления - прежде всего среди них, и я бы спросил об этом НАСТОЯТЕЛЬНО: "Почему вы готовы отменить свой технический персонал по техническим вопросам" на основе другого мнения - особенно, когда указанный человек не так знакомы с нашей настройкой, как мы...

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

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

Удачи вам в этом - я чувствую вашу боль...

Martin

Ответ 14

Я предлагаю вам сначала получить ответную реакцию, опубликовать в Daily WTF.

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

По соображениям развития вы потеряете доступ к экосистеме SQL-сервера, всем библиотекам, инструментам, утилитам.

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

Ответ 15

Самый простой способ опровергнуть этот аргумент - назвать компанию, состоящую из 500 человек, которая обрабатывает данные в этом масштабе с использованием плоских файлов?

Теперь назовите компанию, состоящую из 500 человек, которая не использует реляционную базу данных...

Дело закрыто.

Ответ 16

Здесь действительно что-то необычное. Для того, чтобы кто-то получил правильность терминологии ( "плоский файл" ), но не знал, насколько подавляю глупо идея, то есть она просто не складывается. Я бы хотел быть вашим менеджером нетехническим, но человек, с которым разговаривает ваш менеджер. Это больше похоже на проблему с потерями в переводе.

Вы уверены, что они не означают no-SQL, как если бы вы находились в среде, ориентированной на документ, удаляясь от реляционной базы данных, на самом деле имеет смысл в некоторых отношениях, но при этом имеет много положительных сторон традиции RDBMS.

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

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

Ответ 17

• Время, необходимое для такого массового переписывать/переключаться и огромные $cost

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

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

Менеджеры, например, цифры, так же как и формальный письменный анализ решений. Сравните два предложения по выгодам и рискам, рядом с числовыми значениями. Когда вы доберетесь до 0, чтобы поддерживать и 100 000 000, чтобы конвертировать, они получат смысл.

Ответ 18

Люди, которые не различают плоские файлы и sql, не понимают все аргументы, которые вы говорите ранее.


Объяснение должно быть простым, как это возможно: SQL - это своего рода оболочка поиска /concurrency вокруг плоских файлов.
Все проблемы, которые существуют в настоящее время, останутся даже компанией, собирающейся написать обертку с нуля.

Также вы должны указать другой способ решения текущих проблем, использовать умные слова, такие как расширенная BLL или установить/удалить скриптовую среду.:)

Ответ 19

Вы должны говорить исполнительной. Не сказав этого, заставьте их понять, что они находятся здесь над головой. Здесь несколько боеприпасов:

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

Это работа специалистов PhD. Они хорошо перерабатывают месторождение 20 лет, и это замечательно: это позволяет нам специализироваться на создании бизнес-систем.

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