Распределенный объект, большие данные

У меня есть общий вопрос о больших объектах в памяти и распределенных вычислениях.

У меня есть большой объект, такой как Class.Object, который хранит много данных, таких как более 200 000 объектов, и их число продолжает расти. Как сейчас, это простой объект, созданный и работающий в памяти, и клиенты вызывают данные в нем. Поскольку скорость также важна, я сериализую этого монстра в рабочий стол, как C# BinaryFormatter, загружаю и запускаю их. Это проект WCF, поэтому объект остается в памяти. Мой вопрос заключается в том, как мне масштабировать это на нескольких серверах, например распределенных вычислениях. Есть ли в С# такой инструмент, как "сегментирование базы данных" или что-то в этом роде. Есть ли база данных, в которую я могу сохранить эту информацию. Этот объект не похож на простую таблицу базы данных. Он имеет ссылки вверх и вниз по классам. Все ссылается. Есть хеш-таблицы и т. д. Кажется, что Google делает такого рода чудовищные индексы, используя «осколки» и разбивая данные по разным серверам. Есть ли инструмент и механизм для этого в .NET. Какой здесь подход? Я использую Windows Server AppFabric, чтобы сохранить его в памяти и загрузить, но, похоже, мне нужно разбить этот объект-монстр на части?

Любые указатели и помощь приветствуются.


person iefpw    schedule 27.08.2011    source источник
comment
Тот факт, что объекты имеют ссылки на другие объекты, не означает, что вы не можете использовать базу данных SQL, на самом деле они довольно хороши в этом, используя внешние ключи. Можете ли вы показать пример одного из объектов и как вы их используете?   -  person svick    schedule 27.08.2011


Ответы (2)


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

Но для общего ознакомления и может быть довольно полезной ссылкой может быть вот эта:
Распределенные вычисления CodeProject с Silverlight

Отличная статья, от меня.

Удачи.

person Tigran    schedule 27.08.2011
comment
Ссылка посвящена вызову объектов пользовательского интерфейса из других потоков, здесь это не имеет значения. - person svick; 27.08.2011

Думаю, я не получаю «голосов» за этот ответ, но решение вашей проблемы — это не какая-то техническая сегментация, а лучший дизайн. Если вам нужно постоянно держать в памяти так много объектов, вам нужен действительно хороший стимул для этого. Разве нельзя загружать только часть этого за раз? Если клиент «вызовет данные в нем», клиенту не нужно возвращать всех монстров, не так ли? Если нет, попробуйте разбить это на управляемые части, которые действительно нужны клиенту.

person Random Dev    schedule 27.08.2011