|
|
Регистрация Восстановить пароль |
Повторная активизация e-mail |
Регистрация | Задать вопрос |
Заплачу за решение |
Новые сообщения |
Сообщения за день |
Расширенный поиск |
Правила |
Всё прочитано |
|
|
Опции темы | Поиск в этой теме |
13.05.2014, 18:02 | #11 |
Форумчанин
Регистрация: 23.03.2013
Сообщений: 218
|
Потому что информация на сервер загружается именно файлом. И скачиваться должна файлом.
Файлов много, в сумее более 30 гб. задача сервера по запроссу обрабатывать их, добавляя/убирая из них инфу. Вопрос не об этом, вопрос о вариантах синхронизации и производительности методов работы с ними |
13.05.2014, 19:39 | #12 |
Пользователь
Регистрация: 02.03.2009
Сообщений: 47
|
Дак а файлы-то загружаются вообще в произвольный момент времени, и скачиваются тоже чисто самостоятельно, или это происходит через какой-то Ваш интерфейс загрузки-выгрузки? Если через Ваш интерфейс, то однозначно загоняла бы при загрузке в БД, устраивала бы транзакции, а потом по запросу на выгрузку инфы формировала бы новый файл и отдавала бы его просителю. Прелесть в том, что СУБД сама установит очередность доступа скриптов к данным, чтоб они друг другу не мешали, ну и потом нормализация наше всё - если база нормализована и проиндексирована, работать по идее должно куда быстрее, чем с одной таблицей, полной частично повторяющимися строками. Но если для каждого скрипта загонять текст сырьем в БД и потом снова выгружать - может и не оказаться выигрыша.
|
13.05.2014, 19:48 | #13 |
Форумчанин
Регистрация: 23.03.2013
Сообщений: 218
|
неужели БД может хранить в себе 20-30 ГБ данных? не лопнет ?
Вообще у меня чтото типа серверного хранилища, сами загрузили, файл сутки лежит, изменяется, и через нужное время сами скачивают его. Конечно можно через БД всё сделать, никаких проблем, но если хранить такие объёмы информации, думаю будет хуже, или БД нормально работает с такими данными? |
13.05.2014, 20:09 | #14 |
Пользователь
Регистрация: 02.03.2009
Сообщений: 47
|
Что-то мне кажется, что по-любому СУБД сработает не хуже, чем прямой поиск в файле. Особенно если можно разбить строку на поля, а в части полей подстроки повторяются, т.е. использовать таблицы-"справочники", в результате собственно изменяемая часть данных будет не такая и большая, и СУБД её "прожуёт" куда легче. Хотя врать не буду, с такими объёмами не работала.
UPD: Вон чё нашла: "1)Размер базы данных - параметер весьма критичен! - несколько мегабайт: MS Access, XML, CSV, MS Excel, Парадокс, Dbase, Foxpro/VFP, MySQL, PostgreSQL - до сотни мегабайт: MS Access, Парадокс, Dbase, Foxpro/VFP, MySQL, PostgreSQL, Interbase - гигабайты: MySQL, PostgreSQL, Interbase, Informix, MS SQL Server, Oracle, SyBase, DB/2 - сотни гигабайт и больше: MS SQL Server, Oracle, SyBase, DB/2" Последний раз редактировалось Леди Кошка; 13.05.2014 в 20:10. Причина: дополнение пруфом |
13.05.2014, 22:16 | #15 |
Старожил
Регистрация: 25.02.2007
Сообщений: 4,160
|
нужно знать всю задачу целиком, чтоб понимать что предлагать.. а мы так щас.. абстракно... 20-30 гб... чего? неясно зачем это менять итд.....
Возможно использовать алгоритмы сжатия, что уменьшит размер в сотни раз, кеш, еще что-то .... повторяю нужно знать всю здаачу |
13.05.2014, 22:49 | #16 |
Форумчанин
Регистрация: 23.03.2013
Сообщений: 218
|
думаю тему закрыть можно, т.к. меня интересовали только варианты синхронизации работы.
|
|
Похожие темы | ||||
Тема | Автор | Раздел | Ответов | Последнее сообщение |
Timer. Считаем время работы скрипта | bilibian | Общие вопросы Delphi | 6 | 27.02.2014 22:11 |
результат работы скрипта в ячейке таблицы | MixanMM | PHP | 1 | 31.10.2013 23:27 |
Уменьшение скорости работы скрипта | amdbodia | PHP | 3 | 16.01.2011 20:49 |
Логироване работы TIdTCPServer, проблема с синхронизацией | Altera | Работа с сетью в Delphi | 0 | 05.09.2010 19:42 |
ajax индикатор работы скрипта | ssdm | JavaScript, Ajax | 3 | 08.04.2010 17:04 |