Распараллеливание хранения данных в .NET Core - PullRequest
0 голосов
/ 30 августа 2018

Я немного растерялся в этом задании. Для нашего решения для кэширования существует требование разбивать большой словарь данных на разделы и выполнять над ними операции в отдельных потоках.

Сценарий таков: у нас есть большой пул данных, который должен храниться в памяти (40 м строк), выбранная стратегия должна сначала иметь словарь с ключом int. Этот словарь содержит подмножество из 16 словарей, которые вводятся с помощью guid и содержат класс данных.

Число 16 рассчитывается при запуске и указывает количество ядер процессора * 4.

Класс данных содержит байт [], который в основном представляет собой переведенный набор свойств и их значений, указатель int на словарь метаданных и контрольную сумму.

Затем существует набор функций управления, который заботится о блокировке и назначает / извлекает данные ключа Guid на основе деления первого сегмента guid (8 шестнадцатеричных чисел) на делитель. Этот делитель просто FFFFFFFF / 16. Таким образом, каждому ключу будет назначен соответствующий раздел.

Теперь мне нужно выяснить, как выполнять операции (поиск ключа, итерации и запись) над этими словарями в отдельных потоках параллельно? Буду ли я обернуть эти операции с помощью задач? Или лучше загрузить эти словари бегемотов в отдельные темы?

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

Кроме того, является ли использование словарей хорошим подходом? Их размер ограничен 3 миллионами строк на раздел, и если один заполнен, механизм управления пытается вставить на другой сервер, который использует точно такой же механизм.

Действительно ли .NET является хорошим языком для реализации этого решения?

Буду очень признателен за любую помощь.

1 Ответ

0 голосов
/ 31 августа 2018

Хорошо, поэтому я реализовал ReaderWriterLockSlim и реализовал параллельный доступ через System.Threading.Tasks. Мне также удалось исключить любой объект dataClass из хранилища, теперь это всего лишь словарь байтов [] s.

Он способен хранить все 40 миллионов строк, занимая чуть менее 4 ГБ ОЗУ, и с помощью некоторых осторожных оптимизированных SIMD манипуляций выполняет итерации операций EQUALS, <,> и SUM менее чем за 20 мс, поэтому я полагаю, что эта проблема решена.

Также пропускная способность параллелизма довольно хорошая.

Я просто хотел опубликовать это на случай, если кто-нибудь столкнется с подобной проблемой в будущем.

...