|
40 Тб база, с чего начать?
|
|||
---|---|---|---|
#18+
Нужно организовать хранение примерно 20 миллионов документов, состоящих преимущественно из одного или нескольких файлов в формате DjVu (http://ru.wikipedia.org/wiki/DjVu - если кому интересно что за формат). Один документ, таким образом, занимает в среднем чуть меньше 2 Мб. Соответственно, общий объём базы составит порядка 40 Тб. Формат DjVu выбран, в частности и потому, что он поддерживает слой текста и возможность поиска текста внутри таких файлов. Соответственно и в базе данных должны быть возможности для полнотекстового поиска внутри хранимых DjVu файлов, например, составлением индекса при загрузке в базу или ещё как. Основная нагрузка на базу – выдача документов по запросу и осуществление поиска по тексту внутри. Обновление базы будут происходить достаточно редко, примерно 1000 документов в день добавляться, а изменения среди уже добавленных будут совсем редко происходить. Ну может пара-тройка документов в день максимум изменится. Количество пользователей – примерно 1000, предполагается, что работать с базой они будут активно и один пользователь может запросить в день около 100 документов. Естественно, время ожидания загрузки не должно раздражать пользователей, следовательно оно не должно быть больше минуты, по-любому. Интерфейс для работы клиентов – обычный браузер. Посоветуйте в сторону каких систем и решений начинать думать. Операционная система, СУБД, серверный софт для раздачи, железо для хранения данных, для раздачи их. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.04.2007, 11:30 |
|
40 Тб база, с чего начать?
|
|||
---|---|---|---|
#18+
По-видимому, Yandex.Server. Если нужен русский язык, сложные запросы, морфология. Правда, у них явно не сказано о поддержке djvu. Сделать простейшее индекстирование по отдельным словам несложно и самим, сохранить индекс в бинарных файлах и mmap/bsearch по ним (при этом размер базы не имеет большого значения), но только без учета морфологии, сложных запрсов и т.п. - иначе имхо не оправданы затраты на R&D. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.04.2007, 12:10 |
|
40 Тб база, с чего начать?
|
|||
---|---|---|---|
#18+
Mike7Посоветуйте в сторону каких систем и решений начинать думать. В первую очередь понять, что "найти файл" и "вернуть файл клиенту" - две разных и малосвязанных задачи. Оценить объем индексируемого текста, оценить, с какой попытки поискового запроса пользователь найдет нужный файл, составить список СУБД, поддерживающих полнотекстовый поиск, проанализировать их фичи-ограничения на предмет соответствия вашим потребностям, в интересных вариантах поинтересоваться в соответствующих форумах "а какое железо нужно, чтобы вытянуть поток из [например] 500 поисковых запросов в минуту". Аналогично, но уже мало связано с СУБД - "а что нужно, чтобы веб-сервер прокачивал на клиентов по полгига в минуту из 40тб файловой помойки". ... |
|||
:
Нравится:
Не нравится:
|
|||
10.04.2007, 13:54 |
|
40 Тб база, с чего начать?
|
|||
---|---|---|---|
#18+
Начать нужно с оценки размера необходимых инвестиций в такой проект. Если исходить из грубой оценки: мин. стоимость 1Тб (система хранения) ~ $30K Тогда 40 * $30K = $1.2M. Это - стоимость системы хранения. Прибавим сюда серверы и прочее HW (~ $500K), работы по развертке решения (~$100K - скромно), в итоге получим около $2М. PS Порядок оценок соответствует проектам такого рода, так что есть большая вероятность того, что начальные требования со стороны бизнеса существенно изменятся после знакомства с цифрами. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.04.2007, 15:22 |
|
40 Тб база, с чего начать?
|
|||
---|---|---|---|
#18+
Любая документоимейджинговая система. Есть такие. MS Sharepoint - вообще из коробки, если смените djvu на более распространенный формат. -- "Government is not a solution to our problem, government is the problem." -- Ronald Reagan ... |
|||
:
Нравится:
Не нравится:
|
|||
10.04.2007, 15:42 |
|
40 Тб база, с чего начать?
|
|||
---|---|---|---|
#18+
Кстати, 1Тб в системе хранения на SATA стОит $2000. -- "Government is not a solution to our problem, government is the problem." -- Ronald Reagan ... |
|||
:
Нравится:
Не нравится:
|
|||
10.04.2007, 15:44 |
|
40 Тб база, с чего начать?
|
|||
---|---|---|---|
#18+
2 Someбади Не сомневаюсь, что можно еще дешевле найти. Я говорил о промышленных решениях, способных поддержать работу 1000 пользователей, обеспечить приемлемый уровень надежности и обслуживания, близкий к 7х24. Причем речь шла даже не о HI-END классе, для которого стоимость 1Тб доходит до $100K. Ну и, не учитывалась стоимость поддержки систем резервирования, бесперебойного питания и т.п. PS Прошу не воспринимать данные оценки, как единственно возможные, т.к. они делались исходя из информации по организации весьма серьезной системы хранения в одной из очень успешных российских компаний, которая могла себе позволить такие вложения. Цель моего сообщения - плясать от бюджета, т.к. традиционно бизнес выдвигает максимальные требования, считая, что затраты будут весьма умеренными. Когда же заказчики получают более-менее реальную оценку, то начинают рассматривать варианты и, для данного случая, могут поменять требования к объемам данных, количеству пользователей и времени доступа, например. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.04.2007, 17:33 |
|
40 Тб база, с чего начать?
|
|||
---|---|---|---|
#18+
Я считаю hi-end storage надувательством, для распиливания бюджетов крупных глупых контор. Если бы это было не так, системы гугля, амазона, яндекса и прочих строились бы на них, а не на максимально доступных серийных (commodity) железках. Лишнее бабло лучше пустить на процессоры и ОЗУ в виде индексирующих ферм из тех самых commodity серверов, чтобы быстрее шла индексация. -- "Government is not a solution to our problem, government is the problem." -- Ronald Reagan ... |
|||
:
Нравится:
Не нравится:
|
|||
10.04.2007, 23:11 |
|
40 Тб база, с чего начать?
|
|||
---|---|---|---|
#18+
> о промышленных решениях, способных поддержать работу 1000 пользователей, > обеспечить приемлемый уровень надежности и обслуживания, близкий к 7х24. Какова проектная надежность программно-аппаратного комплекса в Вашем случае и нафига она нужна обычной файлопомойке, можно поинтересоваться? > HI-END классе, для которого стоимость 1Тб доходит до $100K Можно подробнее, что это за железка за столь безумные деньги? Лицевая панель, полагаю, инкрустирована золотом? > которая могла себе позволить такие вложения Любая задача имеет альтернативные решения. Ниоткуда не следует, что в Вашем случае бабло не было просто успешно освоено. > плясать от бюджета В данном случае - бессмысленное занятие. Автор вопроса не понимает, как должна работать такая система. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.04.2007, 00:31 |
|
40 Тб база, с чего начать?
|
|||
---|---|---|---|
#18+
> 1Тб в системе хранения на SATA стОит $2000. Уже сильно дешевле. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.04.2007, 00:42 |
|
40 Тб база, с чего начать?
|
|||
---|---|---|---|
#18+
Разумеется, что создавать такую систему только на основе обсуждения на форуме никому не позволят :) Насчет бюджета могу сказать, что Jimmy где-то угадал, речь примерно о такой сумме и шла, возможно несколько меньшей, но порядок тот же. > В данном случае - бессмысленное занятие. Автор вопроса не понимает, как должна работать такая система. А я разве говорил, что понимаю? Более того, вовсе не я самый главный, максимум чего могу, аргументированно посоветовать что-то выбрать. Насчёт нагрузки я не понял откуда такая цифра в полгига за минуту взялась? Если считать, то у меня получается примерно 50-60 Мб/мин. Насчёт SharePoint - по-моему, этот продукт вообще не для данных ситуаций был придуман, тем более, что он уже зараннее накладывает ограничения на формат файлов. DjVu - и никто не будет что-то другое выбирать. И честно говоря, я не понимаю, почему DjVu плох, если не считать его относительно малой распространенности. Yandex.Server - думали, но боюсь в чистом виде он никак не подойдёт. Собственно, "из коробки" тут ничего не подойдёт, надо будет немало писать самим. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.04.2007, 08:23 |
|
40 Тб база, с чего начать?
|
|||
---|---|---|---|
#18+
SomeбадиЯ считаю hi-end storage надувательством, для распиливания бюджетов крупных глупых контор. Если бы это было не так, системы гугля, амазона, яндекса и прочих строились бы на них, а не на максимально доступных серийных (commodity) железках. Лишнее бабло лучше пустить на процессоры и ОЗУ в виде индексирующих ферм из тех самых commodity серверов, чтобы быстрее шла индексация. -- "Government is not a solution to our problem, government is the problem." -- Ronald Reagan +10 Абсолютно согласен.. Storage systems могут быть оправданы для хранения данных, например, процессингового центра, требуещего очень высокой производительность в режиме 24х7.. Тогда можно использовать фоновый бэкап, автоматическое перемонтирование и т.п. А в иных случаях - имхо просто развод. Mike7 Yandex.Server - думали, но боюсь в чистом виде он никак не подойдёт. Собственно, "из коробки" тут ничего не подойдёт, надо будет немало писать самим. Простите за, возможно, неуместное любопытство, но интересно, что за особенности есть у задачи (кроме формата djvu), которые не реализованы в существующих системах? Дело в том, что аналогичными задачами (работа с БД больших объемов) некоторое время я занимался, поэтому возник профессиональный интерес. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.04.2007, 10:10 |
|
40 Тб база, с чего начать?
|
|||
---|---|---|---|
#18+
> порядок тот же Вас, дружище, развели как кроликов. > Более того, вовсе не я самый главный, максимум чего могу, аргументированно > посоветовать что-то выбрать. Простите, о каких аргументах идет речь, если Вы задачу сформулировать не в состоянии? Совет: оплатите консультацию вменяемого специалиста, сэкономите кучу бабла. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.04.2007, 10:12 |
|
40 Тб база, с чего начать?
|
|||
---|---|---|---|
#18+
Я думаю, проблема в выбиральщиках, заточенных на "допишем сами". Проблемы вообще нет. Все доступно на рынке. google 60,500 for document imaging djvu. vs google 1,190,000 for document imaging pdf searchable text. выбрали в 60 раз менее распространенный формат, чем pdf, и начинают изобретать велосипед ;) -- "Government is not a solution to our problem, government is the problem." -- Ronald Reagan ... |
|||
:
Нравится:
Не нравится:
|
|||
11.04.2007, 10:19 |
|
40 Тб база, с чего начать?
|
|||
---|---|---|---|
#18+
автор> 1Тб в системе хранения на SATA стОит $2000. Уже сильно дешевле. Я считал брэндованные и с терабайтными дисками - чего уж там мелочиться ;) -- "Government is not a solution to our problem, government is the problem." -- Ronald Reagan ... |
|||
:
Нравится:
Не нравится:
|
|||
11.04.2007, 10:20 |
|
40 Тб база, с чего начать?
|
|||
---|---|---|---|
#18+
> чего уж там мелочиться ;) Да конечно, какая фигня: $800 за терабайт или два килобакса, - всего в два с половиной раза дороже. За красЯвую нашлепку на передней панели и гламурный цвет корпуса. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.04.2007, 10:26 |
|
40 Тб база, с чего начать?
|
|||
---|---|---|---|
#18+
Mike7Насчёт нагрузки я не понял откуда такая цифра в полгига за минуту взялась? Если считать, то у меня получается примерно 50-60 Мб/мин. Ну, я не очень представляю, как считать так, чтобы получить 50-60. Твои цифры: тысяча пользователей, сто двухмегабайтных документов в день на пользователя. Рабочий день - 480 минут, для удобства округлим до 500, то есть пользователь запрашивает документ в среднем раз в пять минут, то есть в среднем 200 документов в минуту, 400Мб. Одним словом проще сказать "полгига". Разумеется, это средняя нагрузка, пиковая - отдельный вопрос, тут уже надо смотреть специфику. Если предположить, что нагрузка размазана по 24 часам, средняя соответственно уменьшается втрое, то есть 130Мб. Но как ты получаешь 50-60, я не готов понять. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.04.2007, 11:08 |
|
40 Тб база, с чего начать?
|
|||
---|---|---|---|
#18+
softwarer Но как ты получаешь 50-60, я не готов понять. Вроде ты правильно подсчитал, но и я считал: Нагрузка на сетевой интерфейс: 1 мин на загрузку 2 Мб = 2096Кб/60 ~= 33 Кб/сек. на пользователя надо гарантировать. Возможное число обращений к базе в секунду: 1000 пользователей * 100 запросов в день / 8 часов = 3,47 запроса в секунду. Следовательно, отдавать надо поток 33 Кб/сек * 3.47 = 114.5 Кб/сек с сервера. Для гарантии, пусть 1Мб/сек. Ты вроде тоже правильно подсчитал. Чувствую себя дебилом :) ... |
|||
:
Нравится:
Не нравится:
|
|||
11.04.2007, 12:04 |
|
40 Тб база, с чего начать?
|
|||
---|---|---|---|
#18+
Mike7 1 мин на загрузку 2 Мб = 2096Кб/60 ~= 33 Кб/сек. Маленькое пояснение, а то совсем странно выглядит: 2096 Кб - это именно средний объём, округляемый до 2Мб. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.04.2007, 12:08 |
|
40 Тб база, с чего начать?
|
|||
---|---|---|---|
#18+
Mike71 мин на загрузку 2 Мбправильнее будет "не более 1 минуты на загрузку 2 Мб" Mike7Следовательно, отдавать надо поток 33 Кб/сек * 3.47 = 114.5 Кб/сек с сервера.еще надо умножить на среднюю длительность загрузки, т.к. в каждую секунду выполняются не только запросы поступившие именно в эту секунду, но и те которые поступили до этого. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.04.2007, 12:50 |
|
40 Тб база, с чего начать?
|
|||
---|---|---|---|
#18+
Mike7Возможное число обращений к базе в секунду: 1000 пользователей * 100 запросов в день / 8 часов = 3,47 запроса в секунду. Верно. То есть каждую секунду у сервера запрашивают 3.47 * 2096 ~= 7.1 Мб информации. На какое время он растянет ее отдачу - вопрос второй, но если он не сможет прокачивать 7.1 Мб/сек, он захлебнется (время ожидания начнет монотонно увеличиваться пока соединения не начнут падать по таймауту). Что же до твоего решения, то cмотри внимательно: 2096Кб/60 ~= 33 килобайта в секунду на запрос 1000 пользователей * 100 запросов от пользователя в день / 8 часов = 3,47 запроса в секунду. 33 Кб/сек/запрос * 3.47 запрос/сек = 114.5 Кб (а вовсе не Кб/сек) В мое время это была тема шестого класс школы, контроль размерности. Очевидно, что величина, измеряемая в килобайтах, никак не может являться метрикой пропускной способности. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.04.2007, 14:43 |
|
40 Тб база, с чего начать?
|
|||
---|---|---|---|
#18+
softwarer33 Кб/сек/запрос * 3.47 запрос/сек = 114.5 Кб (а вовсе не Кб/сек) Прошу прощения, уже сам поспешил. Следует читать как: 33 Кб/сек/запрос * 3.47 запрос/сек = 114.5 Кб / сек 2 ... |
|||
:
Нравится:
Не нравится:
|
|||
11.04.2007, 14:49 |
|
40 Тб база, с чего начать?
|
|||
---|---|---|---|
#18+
miksoft Mike71 мин на загрузку 2 Мбправильнее будет "не более 1 минуты на загрузку 2 Мб" Mike7Следовательно, отдавать надо поток 33 Кб/сек * 3.47 = 114.5 Кб/сек с сервера.еще надо умножить на среднюю длительность загрузки, т.к. в каждую секунду выполняются не только запросы поступившие именно в эту секунду, но и те которые поступили до этого. О, верно! Тогда получается, что нужно где-то 6-7 Мб/сек. т.е. где-то 10 Мб/сек. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.04.2007, 17:21 |
|
40 Тб база, с чего начать?
|
|||
---|---|---|---|
#18+
guest_20040621> 1Тб в системе хранения на SATA стОит $2000. Уже сильно дешевле. MAxtor Sata 500 G ~150 USD low level HP server 400 USD держит 7 винтов x 500G = 3.5T ~ 1500 USD 12 серверов x 1500 = 18,000 USD для работы в Hight Safity mode с миррорингом на MSSQL2005 еще 18000 + 1 сервер для свидетеля. итого 40 К максимум для режима 24x7x365 + лицензии на сервера ... |
|||
:
Нравится:
Не нравится:
|
|||
12.04.2007, 21:12 |
|
40 Тб база, с чего начать?
|
|||
---|---|---|---|
#18+
Lepsikитого 40 К максимум для режима 24x7x365 + лицензии на сервера Да уж, такой маааааленький незаметный плюс. Если не изменяет память, двадцать пять тысяч баксов на процессор - итого $625'000 не считая лицензий на операционку - и это ради того, чтобы сэкономить $40'000 на железе. Сильная мысль. Заодно веселая мысль - тратить двадцать пять процессоров на тысячу столь активно работающих пользователей. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.04.2007, 21:23 |
|
40 Тб база, с чего начать?
|
|||
---|---|---|---|
#18+
> low level HP server 400 USD держит 7 винтов x 500G = 3.5T ~ 1500 USD Если Ваша задача - освоить бабло, а не решить задачу, не о чем говорить. > итого 40 К максимум для режима 24x7x365 Могу посоветовать тщательно описать придуманный конфиг - и в FAQ, в раздел "Типичные ошибки". Обратитесь к ближайшему знакомому интегратору, - он Вам расскажет, почему предложенное Вами решение практического применения не имеет, как такие задачи решают и сколько это стоит. Мне - честно - лень; поройтесь на ixbt, там в "серверах" недавно было обсуждение похожей задачи. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.04.2007, 21:50 |
|
40 Тб база, с чего начать?
|
|||
---|---|---|---|
#18+
Предложения "знакомых интеграторов" обычно исходят из балансировки четырех основных целей: - срубить побольше бабла; - сделать план по вендору; - затем уже решить задачу; - и пожалуй, в последнюю очередь, минимизировать головняки; ну и еще бывают комплексы других интересов, например, учесть в предложении любимых богов закупщика. Именно поэтому следует подходить к результатам этих лебедя, рака и щуки с лопатой соли, не меньше ;) ... |
|||
:
Нравится:
Не нравится:
|
|||
12.04.2007, 23:23 |
|
40 Тб база, с чего начать?
|
|||
---|---|---|---|
#18+
> обычно исходят из балансировки четырех основных целей Да. Но при этом никто не ограничивает количество интеграторов. Т. о. из предложенных n решений выбирается наиболее приемлемое. Чем качественнее поставлена задача, тем меньше будет вариантов. > в последнюю очередь, минимизировать головняки Если у интегратора мозгов совсем нет - тогда да, в последнюю очередь. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.04.2007, 00:04 |
|
40 Тб база, с чего начать?
|
|||
---|---|---|---|
#18+
> Чем качественнее поставлена задача, тем меньше будет вариантов. Да, именно так зарубают "ненужных" на экзаменах (и тендерах). Правильный вариант предлагают не интеграторы, а независимые консультанты. -- "Government is not a solution to our problem, government is the problem." -- Ronald Reagan ... |
|||
:
Нравится:
Не нравится:
|
|||
13.04.2007, 09:52 |
|
40 Тб база, с чего начать?
|
|||
---|---|---|---|
#18+
Lepsik guest_20040621> 1Тб в системе хранения на SATA стОит $2000. Уже сильно дешевле. MAxtor Sata 500 G ~150 USD low level HP server 400 USD держит 7 винтов x 500G = 3.5T ~ 1500 USD 12 серверов x 1500 = 18,000 USD для работы в Hight Safity mode с миррорингом на MSSQL2005 еще 18000 + 1 сервер для свидетеля. итого 40 К максимум для режима 24x7x365 + лицензии на сервера Полный бред. Еще даже не сформулирована толком задача, не выбрано ПО, а уже пытаются сформировать требования к железу. Видел я достаточно историй за 12 лет работы, когда "большой проект" начинался с покупки супер-навороченного железа, и, как правило, на этом же и заканчивался.. Либо еще покупался софт, столь же навороченный, после чего возникали ленивые мысли - "а что с этим делать"... ... |
|||
:
Нравится:
Не нравится:
|
|||
13.04.2007, 10:07 |
|
40 Тб база, с чего начать?
|
|||
---|---|---|---|
#18+
> Да, именно так зарубают "ненужных" на экзаменах (и тендерах). Хотите обсудить что-то предметно или просто поговорить о погоде? > Правильный вариант предлагают не интеграторы, а независимые консультанты. Нет. Объясню, почему. Независимый консультант не будет обслуживать поставляемые железки. Независимый консультант не может "дать потестировать" железку из предлагаемого конфига. Независимый консультант не имеет статистики отказов. Независимый консультант не имеет понятия о том, как работает техподдержка вендора или интегратора и прочая, прочая, прочая. Так что максимум, что получится у независимого консультанта - проект сферического коня в вакууме, т. е. булшит для чтения в клозете. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.04.2007, 10:28 |
|
40 Тб база, с чего начать?
|
|||
---|---|---|---|
#18+
softwarer Lepsikитого 40 К максимум для режима 24x7x365 + лицензии на сервера Да уж, такой маааааленький незаметный плюс. Если не изменяет память, двадцать пять тысяч баксов на процессор - итого $625'000 не считая лицензий на операционку - и это ради того, изменяет вам память. $3,700 для Workgroup Edition а стоимость ОС уже входит в стандартную поставку сервера HP а чем больше машин в паралель, тем быстрее можно обработать запрос. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.04.2007, 20:13 |
|
40 Тб база, с чего начать?
|
|||
---|---|---|---|
#18+
guest_20040621> low level HP server 400 USD держит 7 винтов x 500G = 3.5T ~ 1500 USD --Если Ваша задача - освоить бабло, а не решить задачу, не о чем говорить. я так понял по существу вам сказать нечего > итого 40 К максимум для режима 24x7x365 Могу посоветовать тщательно описать придуманный конфиг - и в FAQ, в раздел "Типичные ошибки". guest_20040621> Обратитесь к ближайшему знакомому интегратору, - он Вам расскажет, почему предложенное Вами решение практического применения не имеет, как такие задачи решают и сколько это стоит. Мне - честно - лень; поройтесь на ixbt, там в "серверах" недавно было обсуждение похожей задачи. я сам в компании интеграторе и решаю подобные задачи. google я так понимаю для вас - одна сплошная ошибка ... |
|||
:
Нравится:
Не нравится:
|
|||
13.04.2007, 20:16 |
|
40 Тб база, с чего начать?
|
|||
---|---|---|---|
#18+
kirill_krynkoитого 40 К максимум для режима 24x7x365 + лицензии на сервера Полный бред.[/quot] kirill_krynko Видел я достаточно историй за 12 лет работы, когда "большой проект" начинался с покупки супер-навороченного железа, Сервер низжей ценовой категории за 500-600 долларов (с одного которого уже можно начать) - это у вас супер-пупер железо ? Извините, я китайское барахло своим клиентам не рекомендую ... |
|||
:
Нравится:
Не нравится:
|
|||
13.04.2007, 20:20 |
|
40 Тб база, с чего начать?
|
|||
---|---|---|---|
#18+
Lepsik softwarerЕсли не изменяет память, двадцать пять тысяч баксов на процессор изменяет вам память. $3,700 для Workgroup Edition Любопытная мысль, да вот незадача - Вы упомянули как составную часть решения "мирроринг", а если верить Microsoft-у, он в Workgroup Edition не поддерживается, как и некоторые другие фичи, вполне интересные для работы 40Тб базы. Впрочем, даже если принять эту цифру - раз уж Вы ее назвали, с ней Вам будет спорить точно не с руки - и умножить ее на 25..... контрольный вопрос: это больше сорока тысяч или меньше? Lepsikа чем больше машин в паралель, тем быстрее можно обработать запрос. Угу. Сорок малоактивных пользователей на процессор - просто обалдеть, насколько эффективное решение. Самое оно для распила бабла. Lepsikя сам в компании интеграторе и решаю подобные задачи. Любопытно, любопытно. Имхо любой даже не то что профессионал, а в первую очередь здравомыслящий человек в первую очередь обратит внимание на то, что 40Тб этой задачи вообще не нужно класть в базу; индексировать нужно только текстовую информацию, которой порядка на два меньше. А сотрудник интегратора сразу рекомендует кластер из четвертьсотни машин и лицензий на полмиллиона баксов..... ... |
|||
:
Нравится:
Не нравится:
|
|||
13.04.2007, 21:18 |
|
40 Тб база, с чего начать?
|
|||
---|---|---|---|
#18+
> я так понял по существу вам сказать нечего Почему? - есть, конечно. Например: только абсолютные дебилы используют jbod для нагруженных систем. Продолжать? > я сам в компании интеграторе и решаю подобные задачи Имя интегратора назовите, чтобы случайно не вляпаться. Если честно, полагал, что квалификация сотрудников у интеграторов сильно выше. > google я так понимаю для вас - одна сплошная ошибка Вы уверены, что готовы обсуждать решения google? ... |
|||
:
Нравится:
Не нравится:
|
|||
13.04.2007, 22:56 |
|
40 Тб база, с чего начать?
|
|||
---|---|---|---|
#18+
Иди путем гугула - строй поисковую систему: 1. Сеть распределенных вычислений на недорогих самозборных серверах 2. Разделении серверов хранения, индексирования и управления 3. Б.Д. и О.С. - с открытым кодом и скорее всего это линукс и постгрис Но врядли проект получится дешевле 500к$, а если брать брендовые решения то и еще больше. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.04.2007, 08:59 |
|
40 Тб база, с чего начать?
|
|||
---|---|---|---|
#18+
Читал я тему, спасибо за обсуждение :) Боюсь правда, что технические аргументы при закупках реально будут, если не на последнем, то предпоследнем месте :( Противно. Тем не менее, насколько смогу постараюсь что-то придумать, формально как будто свобода творчества в отделе... Пока думаю, что должно быть три или более сервера: интранет-сайт, хранилище и база для поиска по тексту. Пока основное - это сделать всё-таки хранилище, потому что, хотя поиск по тексту очень важен, но в крайнем случае система будет работать, даже если можно только получать документы из хранилища по их индексу. Думаю, что можно использовать в качестве хранилища. Если честно, то я до сих пор не занимался подобными объёмами данных и опасаюсь, что приемлемое решение в пределах 1Тб, может неприятно подвести в случае 40Тб. Вот, например, что лучше: использовать что-нибудь типа LVM или не заморачиваться и вообще разбить хранилище на штук двадцать-пятьдесят дешёвых серверов с raid-1, raid-1+0 или raid-5 (я даже ещё не уверен, какой raid лучше подойдёт) и предоставить к содержимому дисков простой доступ, так что пользователь будет по запросу перекачивать конкретные файлы. Плюс такого решения, мне кажется в том, что можно его легко масштабировать: нужно, допустим, не 40, а 80 Тб - взяли и поставили ещё 10 компьютеров -- лишь бы через сеть пролезло. То есть, в простейшем случае, имеется веб-морда в которой пользователь вводит номер документа и получает ссылку на файл, доставляемый в кэш на интранет-сервер или даже сразу ссылку на него, если на всех файлохранилищах поднять http или ftp сервер. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.04.2007, 02:03 |
|
40 Тб база, с чего начать?
|
|||
---|---|---|---|
#18+
Winchester Systems FlashDisk FC-3494: быстрый массив дисков суммарным объемом 28,8 Тб Компания Winchester Systems, специализирующаяся на решениях в области хранения данных, анонсировала выпуск высокопроизводительного массива дисков с интерфейсом Fibre Channel. К особенностям новинки производитель относит высокое быстродействие, большую емкость и высокую надежность, достигаемую за счет поддержки RAID 6. Максимальный объем массива FlashDisk FC-3494 составляет 28,8 Тб при условии использования одного базового модуля с одиночным или дублированным контроллером RAID и до пяти модулей расширения, предназначенных для установки винчестеров. Суммарное количество накопителей в этом случае составляет 96 штук. Речь идет о накопителях объемом 300 Гб с интерфейсом Fibre Channel и скоростью вращения шпинделя 10 или 15 тыс.об/мин. Модель с дублированным контроллером обеспечивает установившуюся пропускную способность 1,5 Гб/с и выполнение 120 тыс. операций ввода-вывода в секунду. Конфигурация RAID 6 защищает от потери информации в случае одновременного отказа двух накопителей. Специалисты оценивают увеличение среднего времени наработки до потери данных (Mean Time To Data Loss, MTDL) в случае RAID 6 по сравнению с RAID 5 в 500-30000 раз. До четырех хостов Fibre Channel можно подключить к FlashDisk FC-3494 напрямую, что устраняет потребность в дополнительном оборудовании. Предусмотрен выбор конфигураций RAID 15 и RAID 16, которые обеспечивают максимальный уровень надежности (No Single Point of Failure, NSPF) за счет дублирования массивов RAID 5 или RAID 6, соответственно. Поставки FlashDisk FC-3494 уже начались, цена базовой конфигурации не превышает 20000 долларов. Источник: Winchester Systems ... |
|||
:
Нравится:
Не нравится:
|
|||
13.05.2007, 03:38 |
|
40 Тб база, с чего начать?
|
|||
---|---|---|---|
#18+
Посмотрите решения предлагаемые в http://www.saperion.ru/ не знаю это ли вам нужно? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.05.2007, 14:17 |
|
40 Тб база, с чего начать?
|
|||
---|---|---|---|
#18+
Mike7Нужно организовать хранение примерно 20 миллионов документов, состоящих преимущественно из одного или нескольких файлов в формате DjVu (http://ru.wikipedia.org/wiki/DjVu - если кому интересно что за формат). Один документ, таким образом, занимает в среднем чуть меньше 2 Мб. Соответственно, общий объём базы составит порядка 40 Тб. Формат DjVu выбран, в частности и потому, что он поддерживает слой текста и возможность поиска текста внутри таких файлов. Соответственно и в базе данных должны быть возможности для полнотекстового поиска внутри хранимых DjVu файлов, например, составлением индекса при загрузке в базу или ещё как. Основная нагрузка на базу – выдача документов по запросу и осуществление поиска по тексту внутри. Обновление базы будут происходить достаточно редко, примерно 1000 документов в день добавляться, а изменения среди уже добавленных будут совсем редко происходить. Ну может пара-тройка документов в день максимум изменится. Количество пользователей – примерно 1000, предполагается, что работать с базой они будут активно и один пользователь может запросить в день около 100 документов. Естественно, время ожидания загрузки не должно раздражать пользователей, следовательно оно не должно быть больше минуты, по-любому. Интерфейс для работы клиентов – обычный браузер. Посоветуйте в сторону каких систем и решений начинать думать. Операционная система, СУБД, серверный софт для раздачи, железо для хранения данных, для раздачи их. готов показать живой пример такой базы с кучей возможных вкусностей вполть до автоматической рубрикации ваших документов и т.д. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.08.2007, 22:38 |
|
40 Тб база, с чего начать?
|
|||
---|---|---|---|
#18+
Mike7Думаю, что можно использовать в качестве хранилища. Если честно, то я до сих пор не занимался подобными объёмами данных и опасаюсь, что приемлемое решение в пределах 1Тб, может неприятно подвести в случае 40Тб. Вот, например, что лучше: использовать что-нибудь типа LVM или не заморачиваться и вообще разбить хранилище на штук двадцать-пятьдесят дешёвых серверов с raid-1, raid-1+0 или raid-5 (я даже ещё не уверен, какой raid лучше подойдёт) и предоставить к содержимому дисков простой доступ, так что пользователь будет по запросу перекачивать конкретные файлы. Я воздержусь от масштабного участия в дискуссии, просто маленькое замечание из собственного личного опыта. Попытка сбора масштабного RAID из стандартных (S)ATA-дисков >500Гб в ряде случае может оказаться неудачной идеей. По крайней мере, в первых выпусках этих дисков были специальные RAID-edition модификации. А ставя обычные, сборщик рисковал одномоментным вылетом сразу нескольких дисков в массиве - были проблемы с излишней синхронизацией передвижения головок на разных дисках. Поскольку мои собственные задачи были достаточно специфичными (тоже информационный архив, некритичный в смысле высокой степени готовности), я просто отказался от RAID массивов в пользу комбинации JBOD и правильно построенного резервного копирования. Соответственно, если говорить о low-end решении, то я советовал бы действительно остановиться на каком-то движке типа локального яндекса в комплекте с батареей из не-RAID дисков. Ставите сервер под Linux, по мере роста архива добавляете винты (с точки зрения стоимости гигабайта сейчас оптимальнее 500Гб, с точки зрения физических размеров системы - 750 или 1Тб). После заполнения мест под внутренние устройства на первом сервере, ставите рядом второй, файловую систему подмонтируете по Samba или NFS к первому... и продолжаете процесс. Никаких жёстких требований по производительности сервера я в такой задаче не вижу, в показанном Вами масштабе задачи можно хоть старые десктопы под это дело утилизировать, набивая их винтами и по неообходимости доставляя оперативку. 1000 пользователей * 100 документов в день (считая, что у нас 8 часовой рабочий день - это ~3.5 запроса в секунду. Яндекс-сервер наверное должен справляться - единственное, что не понятно, будет ли он искать DJvu, на сайте этот формат не включен в список поддерживаемых, но если Вы этот сервер купите - Вам его, конечно добавят. Или, может уже и добавили, но забыли написать. Кроме Яндекса такие же задачки решает Stack Systems (разработчики Рамблера), а можно пробовать и какую-то бесплатную искалку посмотреть... ... |
|||
:
Нравится:
Не нравится:
|
|||
31.08.2007, 03:42 |
|
40 Тб база, с чего начать?
|
|||
---|---|---|---|
#18+
40 TB текста, какие еще интригаторы с MSSQL?!! Стоит обратить внимание на опыт Google, Amazon с файловой системой и распределенным поиском. Однако написать самим будет затруднительно. Попробовать готовые Document Management System, однако наверняка ни одна не знает, что такое формат DjVu. Попробовать прикрутить поисковые индексаторы, я слышал у кого-то хорошо получалось с Apache Lucene ... |
|||
:
Нравится:
Не нравится:
|
|||
08.10.2007, 15:58 |
|
40 Тб база, с чего начать?
|
|||
---|---|---|---|
#18+
2 Mike7 Хранение таких объёмов документов это одно (как уже кто-то говорил выше), но поиск совсем другое. Хотелось бы примерно оценить размер индекса ( тынц ). Насколько я понял, 2 Мб это размер всего файла djvu. Каков примерный объём собственно текстовых данных подлежащих индексации? Насколько сильно/слабо пересекается содержимое документов (тесктовое естественно, от этого зависит размер индекса)? У вас уже есть 20 млн. документов или это максимально/примерно планируемое количество? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2007, 14:36 |
|
40 Тб база, с чего начать?
|
|||
---|---|---|---|
#18+
Если еще актуально - встречал в упоминание в postgresql про Tsearch2 - full text search extension for PostgreSQL Authors * Oleg Bartunov <oleg@sai.msu.su>, Moscow, Moscow University, Russia * Teodor Sigaev <teodor@sigaev.ru>, Moscow, Delta-Soft Ltd.,Russia Поддерживает русский. Как бюджетное решение для индексации и поиска :) OpenSource. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.11.2007, 05:32 |
|
|
start [/forum/topic.php?all=1&fid=33&tid=1548955]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
416ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
66ms |
get tp. blocked users: |
2ms |
others: | 263ms |
total: | 796ms |
0 / 0 |