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

Question

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

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

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

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

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

Answer 4

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

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

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

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

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

Answer 5

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

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

Answer 6

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

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

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

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

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

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

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

Answer 7

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

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

Answer 8

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

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

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

Answer 9

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

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

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

Answer 10

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

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

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