Потоки ,память, рассуждения

[Heneken87]

Доброго времени суток профессионалы!
Тема скорее для обсуждения, лично по мне она интересная.
Задача - создать компонент "таблица" с большой масштабируемостью.
Под масштабом понимается 100-200 колонок от 100 тыс до 500 тыс строк. Это основная задача, второстепенная это удобная навигация и отображение данных в самом компоненте(тут вопросов нет).

Естественно в память приложения такой объем данных не влезет, вторым моментом является то, что таблица должна работать как с БД напрямую для Windows, так и получать данные в JSON для платформ Android и IOS. Получить такой объем данных сразу, задача так же утыкается в память.

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

Отталкиваясь от минимума,считаем что у нас 32 битная архитектура, поэтому в распоряжении максимум 1 гб памяти, остальное оставим на само приложение.

Примерная реализация:
1- На первом этапе получить из БД только ID и уложить их в упорядоченный по возрастанию массив INTEGER. - тут сразу можно получить Out OF Memory, если ИД слишком много, проблему можно обойти, если получить файл и сохранить его локально, чтобы можно было маппить.
2 - Условно разбить полученный массив на блоки (по 10-20 тыс в блоке)
3 - Создать для каждого блока поток и получить из БД необходимые данные в соответствии с их ID,далее либо парсить данные и сохранять в файл локально либо оставить жить в потоке
4 - Создать полосу прокрутки с MIN 0 и MAX = Length(массива пункта 1) - 1
5 - Создать визуальный компонент, от TControl (FMX)или TreeView, но тут не важно, можно даже TListBox(FMX), кол-во строк будет ровно столько, сколько помещается в отведенную под компонент область.
6 - Зная диапазон блока и положение скролла, для отображения информации использовать нужный блок находящийся в потоке или области чтения(если работа с файлом).

Я не работал с потоками в таких объемах. И главный вопрос состоит в следующем, если каждый поток займет примерно по 500 МБ памяти, то получу лия OutOfMemory на 3-4 потоке? Если вывалиться, то выходом будет являться парсинг и сохранение его в единый файл, JSON,XML и.т.д. хоть свой формат, это не принципиально, для этого и 1 потока будет достаточно, только ради того, чтобы не висла ПО. А вывод информации уже построить через маппинг файла хранящегося локально.
Если у кого то есть идеи или вы уже реализовывали что-то подобное, прошу поделиться опытом.
СПАСИБО!

P/S: Варианты на подобии лаб куба или проработка гибкого интерфейса для пользователя в направлении (укажи условие, выбери значение, нажми показать) не подойдут. Сама таблица будет не плоской, она призвана отражать достаточно глубокую древовидную структуру в удобоваримом для глаз формате. Разворачивающиеся списки, расшифровка кодов, если значение в ячейке относиться к справочнику, изображения ,вложения и.т.д. ИЗ БД нужно получить абсолютно все, не обращая внимание надо это пользователю или нет. Потому что сегодня ему НЕ надо, а завтра запонадобилось. Будет иметь возможность фильтрации точно. Сама таблица будет работать с разными СУБД. FireBird,MsSQl, Oracle. По факту, подобная таблица это 70% всей ПО, и ее создание решает кучу проблем и экономит просто огромное кол-во времени при разработке кроссплатформенных приложений, потому что просто надоело на каждый чих что то ваять с 0.
КОГО ПОДОБНАЯ ИДЕЯ ЗАИНТЕРЕСОВАЛА, ПРОШУ ОТПИСАТЬ,ПОДЕЛИТЬСЯ ОПЫТОМ И ОКАЗАТЬ СОДЕЙСТВИЕ. ФРОНТ И БЕКЭНДЫ ОТЗОВИТЕСЬ!)) ЕСЛИ ВСЕ ПОЙДЕТ ХОРОШО, ГОТОВЫЙ К УСТАНОВКЕ КОМПОНЕНТ МОЖНО ВЫЛОЖИТЬ ТУТ, ЧТОБЫ ВСЕ ПОЛЬЗОВАЛИСЬ! ЕЩЕ РАЗ СПАСИБО!

[Heneken87]

Жаль нет откликов, тему стоит закрыть. Все соло сделаю.