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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    • индексирование
    • Обработка транзакции
    • логирование
    • Контроль доступа
    • Представление
    • Безопасность

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

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

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

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

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

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

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

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

    1. Целостность данных. Механизмы SQL предоставляют встроенные механизмы (отношения, ограничения, триггеры и т. Д.), Которые очень упрощают уменьшение количества «плохих» данных в вашей системе. Если вы используете плоские файлы, вам нужно будет вручную передать все ограничения данных.
    2. Дополнительный поиск данных – SQL-механизмы с помощью операторов SELECT обеспечивают средство фильтрации и суммирования ваших данных с очень маленьким кодом. Если вы используете плоские файлы, для получения одинаковых результатов требуется значительно больше кода.

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

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

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

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

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

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

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

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

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

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

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

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

    Надеюсь, это поможет.

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

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

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

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

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

    Pro DB:

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

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

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

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

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

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

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

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

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

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

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

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

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

    Мартин

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

    Давайте будем гением компьютера.