Какие альтернативы хранению базы данных SQL для веб-сайта?

Question

База данных SQL излишня, если ваши потребности в хранилище невелики. Когда я был маленьким и тупым, я использовал текстовый файл и flock () редактировал его, когда мне нужно было получить к нему доступ. Это не масштабируется, но я все еще чувствую, что решения, не связанные с базами данных, полностью игнорируются в Web 2.0.

Кто-нибудь не использует базу данных SQL для хранения? Какие есть альтернативы?

Answer 1

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

Так что, если вашему приложению не нужно что-то очень конкретное, не беспокойтесь. Большинство альтернатив намного сложнее в использовании и имеют меньшую производительность.

Answer 2

SQLite придуман для этого.

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

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

Странно, что никто уже не упомянул об этом?

Answer 3

CouchDB (http://couchdb.apache.org/index.html) - это база данных, не относящаяся к SQL, и, кажется, популярный в наши дни проект, а также Google Bigtable, или GT.M (http://sourceforge.net/projects/fis-gtm), который существует вечно .

Объектные базы данных также имеются в большом количестве; dbforobjects (http://www.db4o.com/), ZODB (http://www.zope.org/Products/StandaloneZODB), просто назвать несколько.

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

Answer 4

Распределенная хеш-таблица, такая как google bigtable или hadoop , представляет собой простую и масштабируемую базу данных, отличную от SQL, и часто подходит для веб-сайтов гораздо лучше, чем база данных SQL. SQL отлично подходит для сложных реляционных данных, но большинство веб-сайтов не имеют этого требования. Большинство веб-сайтов хранят и извлекают данные в нескольких формах, и им не нужно выполнять сложные операции с данными.

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

Answer 5

Я бы не выбрал, использовать ли базу данных SQL, исходя из того, сколько данных я хотел сохранить - я бы выбрал на основе , какого типа данных я хотел бы сохранить и как их использовать ,

Википедия определяет базу данных как: База данных - это структурированная коллекция записей или данных, которые хранятся в компьютерной системе . И я думаю, что ваш ответ лежит там: если вы хотите хранить записи, такие как учетные записи клиентов, права доступа и т. Д., То БД, такая как mySQL или SQLite или что-то еще, не является избыточным. Они дают вам проверенный и надежный механизм управления этими записями.

Если, с другой стороны, ваш веб-сайт хранит и доставляет неизменный контент на основе файлов, такой как PDF-файлы, отчеты, mp3-файлы и т. Д., То более чем достаточно просто сохранить их в четко определенной директории на диске. Я также включил бы здесь XML-документы: если бы у вас был, например, производственный отдел, который создавал статьи для веб-сайта в формате XML, нет необходимости помещать их в БД - сохраняйте их на диске и используйте XSLT для их доставки.

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

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

Answer 6

Я бы сказал, что это не зависит от того, храните ли вы меньше или больше информации, это зависит от того, как часто вы запрашиваете хранимые данные. Менеджеры баз данных превосходно подходят для кэширования запросов, поэтому они часто являются лучшим выбором в плане производительности. Однако, если вам не нужна динамическая веб-страница и вы просто загружаете статические данные - возможно, текстовый файл - лучший вариант. В каком формате хранятся данные (например, XML, JSON, ключ = пара), не имеет значения - это операции ввода-вывода, которые сильно влияют на производительность.

При разработке веб-приложений я всегда использую СУБД в качестве основного хранилища данных. Если веб-приложению не нужно обслуживать динамические данные при каждом запросе, я просто применяю функцию кеширования, хранящую данные в файле кеша, который запрашивается, когда новые данные не были добавлены в первичный источник данных (СУБД). 1003 *

Answer 7

Вероятно, это зависит от того, насколько динамичен ваш сайт. Однажды я использовал вики-программу, которая использовала RCS для проверки и извлечения текстовых файлов. Я не рекомендовал бы это решение для чего-то, что получает столько же обновлений, сколько StackOverflow или Wikipedia. Суть базы данных в том, что они хорошо масштабируются, и разработчики ядра СУБД выяснили все незначительные детали одновременного доступа, балансировки нагрузки, репликации и т. Д.

Answer 8

Это зависит от того, что вы храните. Мой блог использует Blosxom (написанный на Perl, но подобное можно было бы сделать для PHP), где каждая отдельная запись представляет собой отдельный текстовый файл. Первая строка - простой текст (заголовок), а остальные - неограниченный HTML. Следуя нескольким простым правилам, они формируют простую, но эффективную структуру ведения блогов.

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

Answer 9

Я использовал LINQ to XML в качестве источника данных в проекте .NET. Это было небольшое решение, в котором использовалось кэширование для уменьшения проблем с производительностью. Я бы сделал это снова для быстрого сайта, который просто должен хранить данные в общем месте без увеличения требований к серверу

Answer 10

Чек CouchDB .