Хорошо работают базы данных на основе плоских файлов? [закрытый]

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

Добавьте это в свой файл компонента и используйте его в шаблоне, привязав его к событию.

Я добавил столько комментариев, сколько мне показалось бы полезным, но дайте мне знать, если вы запутались в какой-либо строке.

public uploadFile(files: FileList) {
    let results = [];
    if (files && files.length > 0) {
      const file: File = files.item(0);//assuming only one file is uploaded
      console.log('Uplaoded file, Filename:' + file.name + 'Filesize:' + file.size + 'Filetype:' + file.type);
      const reader: FileReader = new FileReader();
      reader.readAsText(file);
      reader.onload = (e) => {
        const fileContent: string = reader.result as string;
        console.log('fileContent:' + fileContent);
        const lines: string[] = fileContent.split('\n'); //this depends on your line end character, I'm using \n in general
        //lines is an array of string, such as "Sham went to school", loop over it and process as you like
      };
    }
  }

Вы можете использовать его в своем шаблоне, например:


11
задан Robert Nickens 2 December 2008 в 03:56
поделиться

10 ответов

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

Почтовые серверы и серверы NNTP прошлого действительно раздвинули границы того, как далеко можно действительно взять эти вещи (который на самом деле довольно далек - файловые системы могут иметь миллионы файлов и каталогов).

Плоский файл DBS, который два самых больших слабых мест индексируют и атомарные обновления, но если домен подходит, они не могут быть проблемой.

Но Вы можете, например, с надлежащей блокировкой, делать "атомарное" индексное обновление с помощью основных команд файловой системы, по крайней мере, на Unix.

Простой случай имеет процесс индексации, пробегающий данные для создания нового индексного файла под временным именем. Затем когда Вы сделаны, Вы просто переименовываете (или системный вызов, переименовывают (2) или оболочка mv команда), старый файл по новому файлу. Переименуйте и mv являются атомарными операциями в системе Unix (т.е. она или работает, или она не делает и никогда нет отсутствия "промежуточного состояния").

То же с созданием новых записей. В основном запишите файл полностью во временный файл, затем переименуйте или mv он в к его заключительному месту. Затем у Вас никогда нет "промежуточного" файла в "DB". Иначе у Вас могло бы быть состояние состязания (такое как процесс, читая файл, который все еще пишется и может добраться в конец, прежде чем запись завершена - ужасное состояние состязания).

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

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

Если Вы помещаете миллион файлов в каталог, там может настраивать проблемы, к которым Вы захотите заглянуть, но из того поля больше всего обработает 10-е тысяч легко. Просто помните, что, если необходимо ПРОСКАНИРОВАТЬ каталог, там будет большим количеством файлов для сканирования. Разделение с помощью каталогов помогает предотвратить это.

Но что все зависит от Вашей индексации и поиска методов.

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

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

Если все Ваши файлы находятся в той же файловой системе, то жесткие ссылки также дают Вам опции (так как они также являются атомарными) с точки зрения помещения того же файла в различных местах (в основном для индексации).

Например, Вы могли иметь "сегодня" каталог, "вчера" каталог, каталог "Java" и фактический каталог сообщения.

Так, сообщение могло быть связано в "сегодня" каталог, каталог "Java" (потому что сообщение отмечено с "Java", скажите), и в его заключительном месте (скажите что /articles/2008/12/01/my_java_post.txt). Затем в полночь Вы выполняете два процесса. Первый принимает все файлы "сегодня" каталог, проверки их создавать дату, чтобы удостовериться, что они не "сегодня" (так как процесс может занять несколько секунд, и новый файл мог бы красться в), и переименовывает те файлы к "вчера". Затем, Вы делаете то же самое для "вчера" каталог, только здесь Вы просто удаляете их, если они устарели.

Между тем файл находится все еще в "Java" и ".../12/01" каталог. Так как Вы используете файловую систему Unix и жесткие ссылки, "файл" только существует однажды, они - все просто указатели на файл. Ни один из них не файл, они являются всеми одинаковыми.

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

В транзакционном DB Вы сделали бы это внезапно.

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

16
ответ дан 3 December 2019 в 01:39
поделиться

(ответ скопирован и измененный отсюда),

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

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

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

13
ответ дан 3 December 2019 в 01:39
поделиться

Это было сделано с asp.net с Dasblog. Это использует хранение файлов.

Несколько деталей перечислены на этой более старой ссылке. http://www.hanselman.com/blog/UpcomingDasBlog19.aspx

Можно также получить больше деталей о http://dasblog.info/Features.aspx

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

3
ответ дан 3 December 2019 в 01:39
поделиться

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

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

Нет ничего неправильно, чем изобретение велосипед (в конце концов, Linux был просто, что), но имеют в виду Ваши ожидания и обязательство времени.

2
ответ дан 3 December 2019 в 01:39
поделиться

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

Однако некоторые указывали на SQLite, который делает это - задание очень хорошо. Так как Вы используете Java, Ваш наилучший вариант состоял бы в том, чтобы использовать HSQLDB, который делает точно то же как SQLite, но реализован в Java и встраивает в Ваше приложение.

2
ответ дан 3 December 2019 в 01:39
поделиться

Ужасная идея. Добавление включило бы поиск в конец файла каждый раз, когда Вы хотите добавить что-то. Обновление потребовало бы перезаписи всего файла каждый раз. Чтение включает сканирование таблицы (или поддержание отдельного индекса, который имел бы те же проблемы с записью/обновлением). Просто используйте базу данных, если, конечно, Вы не повторно реализуете весь материал, который RDBMS уже обеспечивает для создания решения даже умеренно масштабируемым.

0
ответ дан 3 December 2019 в 01:39
поделиться

Большую часть времени база данных на основе плоских файлов достаточно теперь. Но Вы будете благодарить свое младшее сам при запуске проекта с базы данных. Это могло быть SQLite, если Вы не хотите настраивать целую систему баз данных как PostgreSQL.

2
ответ дан 3 December 2019 в 01:39
поделиться

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

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

Программное обеспечение DBMS также использует их для журналов.

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

0
ответ дан 3 December 2019 в 01:39
поделиться

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

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

Итак, почему бы не использовать полноценный DBMS во-первых?

Вы сэкономите себе время и деньги, связанные с записью (и перезапись много раз, я гарантирую), если Вы просто пойдете с одной из бесплатных опций (SQLite, MySQL, PostgresSQL, и так далее).

0
ответ дан 3 December 2019 в 01:39
поделиться

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

0
ответ дан 3 December 2019 в 01:39
поделиться
Другие вопросы по тегам:

Похожие вопросы: