1. Два списка должны быть отсортированны в «неубывающую последовательность» до начала обработки: cells и antsToCells(отсортированный по cells). Это условие лежит в основе работы алгоритма.
2. В память (HashSet) полностью помещается ants, а файлы cells и antsToCells (за счёт строгой последовательности cell-идентификаторов) читаются последовательно один раз, в ходе выполнения ants-цикла.
Вопросы:
1. Во сколько вы оцениваете потребность в памяти (сколько RAM должно быть на компе), чтобы обеспечить обработку миллиарда записей?
2. Как вы будете решать задачу, для 10 миллиардов?
3. 100000000 (сто миллионов) записей (ants, cells, antsToCells), на которых производится текущее тестирование, занимают 14 Гб. Значит миллиард займёт 140 Гб. Допустим есть такой поставщик/источник данных (140 Гб в миллиарде записей). Сможет ли этот поставщик данных поставлять отсортированные данные? А, если нет (сервера опечатаны)? Как вы будете решать такую задачу?
Вы это действительно серьёзно? Вы даже не реализовали сортированного списка тестовых данных для «честных» GUID-ов. Я даже не приступал к тестированию вашего решения на больших данных, потому что это бессмысленно, ваше решение имеет ограничение на размер списка.
Конечно. Для каждой записи в списке связей можно проверить, какого типа в ней муравей, и если он того типа, по которому гоняется тест, проверить, занесен ли он в нужный файл, и указана ли там правильная ячейка.
Мммм… Похоже, я перестал понимать, что вы не понимаете. Решите задачу, так как вы сами её понимаете. Наверное это будет самым разумным подходом. Я всегда готов оказать посильную помощь, задавайте любые вопросы.
Ээээ… то есть вывести данные из таблицы можно, а вывести данные из индекса (который сопоставимого размера) — не хватает ресурсов? Но как?
Пока, возникли проблемы с простой сортировкой списка.
В реальной жизни нет проблем с сортировкой списка, потому что в реальной жизни сортировка списка происходит за рамками задачи.
Я перестал понимать ход ваших мыслей. О каких индексах и о каких рамках вы говорите? Сделайте простой сортированный список на GUID-ах и О'кей. Но вы утверждаете, что проблема в скорости. Хорошо, предложите другой подход. Я повторяю — решение этой проблемы мне неизвестно.
Объясняю. Индекс для сортировки не поможет, так как ресурсы, требуемые для запроса-вывода, значительно превышают ресурсы любого мыслимого сервера.
Строить индекс или нет для обеспечения простого несортированного запроса на таком объёме данных? Не буду вводить вас в заблуждение — этот вопрос требует изучения.
Ну нет, так не работает
Браво! Вы меня не перестаёте удивлять! Я честно признался, что красивое решение мне неизвестно. Вы, совершенно добровольно, взялись за задачу (от которой я вас отговаривал), сами сформировали требования (против которых я всего лишь не стал возражать), но задача оказалась не постой (так бывает). Не понимаю, какой ответ вы от меня ожидаете получить? Я повторяю — мне красивого и технологичного решения этой задачи неизвестно (я её конечно же продумывал).
Какие проблемы у вас могут возникнуть «в реальной жизни»?
Пока, возникли проблемы с простой сортировкой списка. Пока не получается найти решения. Это можно «записать в книжечку». По-моему это очень хороший «сухой остаток» и потраченное время нельзя назвать «бессмысленно потраченным».
Меня устроят любые. Всё, что я делаю — задаю (очень) простые вопросы, а решения по вашей разработке (на которую вы совершенно добровольно согласились) конечно должны принимать вы.
В такой ситуации полезно пойти к начальнику
Вопрос, конечно, не технический, а организационный. Но я бы не стал ходить к начальнику, если, конечно, это не ваш близкий родственник или хороший знакомый. В такой ситуации, приоритет контракта с Заказчиком и наличие мотивированного ПМ-а в этом контракте, для любого начальника, на порядок (или два) выше личного недовольства, пусть даже гениального, разработчика. А ПМ-то чем виноват? В 99% он в той-же шкуре, что и разработчик.
Какой сценарий вам интереснее? Мне кажется, что второй правильнее.
Я думаю, что было-бы интереснее и правильнее использовать подход, когда для каждого муравья есть ячейка и, некоторые муравьи, могут жить в нескольких ячейках (то есть список связей больше количества муравьёв). Проверить функциональность алгоритма на «бездомных муравьёв» можно даже просто ручным удалением записей на малых данных, а на больших данных смысла проверять нету.
когда я сдаю систему, есть ПМИ
Интересно посмотреть на ПМИ, где прописано, что зависимости получаются случайным образом и не проверяются (где вы таких Заказчиков находите?).
Кроме того, любые требования ТЗ, ПМИ, рабочий план-график и т.д. всегда можно «уточнить». Разве вам не знакома ситуация, когда завтра/на следующей неделе должна сдаваться система,
но к вам подходит ПМ и ставит в известность, что с Заказчиком подписаны «небольшие» изменения, «не влияющие на сроки», которые надо срочно доработать. Иначе контракт закрывается, нет финальной оплаты, прощай премия.
но скорость генерации падала даже не как n log n от объема
Я считаю, что задача, фактически, состоит из двух этапов:
1. Подготовка тестовых данных;
2. Подготовка результата;
Вы поторопились приступить ко второму, не разобравшись с первым.
А первый этап (подготовка результатов) уже начинает преподносить свои сюрпризы. Оказывается расчитывать на последовательность данных (препроцессинг) не стоит. Скорее наоборот — препроцессинг невозможен. Или привидите пример, как вы собираетесь выгружать отсортированные данные такого объёма из, например, СУРБД?
Но я с удовольствием послушаю про алгоритм, который бы генерил полный набор данных со случайным распределением.
Я вообще не понимаю, зачем вам нужно здесь случайное распределение.
Объясняю. Муравьёв — 1000, ячеек — 1000, связей — 1000. Муравьёв типа 255 — 373. В результате — 40 записей. Вы сдаёте систему. Ни один приёмщик вам акты не подпишет.
Хорошо, вы утверждаете, что таким образом (используя ненастоящие GUID-ы) имитируете препроцессинг «я не зря спрашивал, разрешен ли препроцессинг». Что вам мешает на этапе генерации провести этот «препроцессинг» на основе «честных» GUID-ов (конечно это немного усложнит генератор).
Нет, это не важно. Важно, чтобы последовательность была неубывающей.
Вы меня удивляете. Я, например, не вижу абсолютно никакой разницы между понятиями «ненастоящие GUID-ы» и «Важно, чтобы последовательность была неубывающей». Это — «подтасованные данные».
Неужели вас может интересовать результат, полученный на «подтасованных данных»?
Поселённых окажется около 40, что соответствует вашим результатам
Это понятно (посмотрел код), данные для таблицы связи формируются случайным образом. Но отлаживать функциональную часть удобнее и правильнее на небольшом объёме целостных данных.
Для парсера важно, что и в файле cells, и в antsToCells имена ячеек идут в лексикографическом порядке (Guid не убывают).
Если для парсера важно, чтобы GUID-ы были «ненастоящими» и последовательными — такое условие нарушает «чистоту» эксперимента.
GUID-ы, которые на самом деле GUID-ами не являются, в природе не существуют, а если существуют, то это можно рассматривать как «информационное преступление».
Правильно ли я понял:
1. Два списка должны быть отсортированны в «неубывающую последовательность» до начала обработки: cells и antsToCells(отсортированный по cells). Это условие лежит в основе работы алгоритма.
2. В память (HashSet) полностью помещается ants, а файлы cells и antsToCells (за счёт строгой последовательности cell-идентификаторов) читаются последовательно один раз, в ходе выполнения ants-цикла.
Вопросы:
1. Во сколько вы оцениваете потребность в памяти (сколько RAM должно быть на компе), чтобы обеспечить обработку миллиарда записей?
2. Как вы будете решать задачу, для 10 миллиардов?
3. 100000000 (сто миллионов) записей (ants, cells, antsToCells), на которых производится текущее тестирование, занимают 14 Гб. Значит миллиард займёт 140 Гб. Допустим есть такой поставщик/источник данных (140 Гб в миллиарде записей). Сможет ли этот поставщик данных поставлять отсортированные данные? А, если нет (сервера опечатаны)? Как вы будете решать такую задачу?
Вы это действительно серьёзно? Вы даже не реализовали сортированного списка тестовых данных для «честных» GUID-ов. Я даже не приступал к тестированию вашего решения на больших данных, потому что это бессмысленно, ваше решение имеет ограничение на размер списка.
Я не возражаю
Мммм… Похоже, я перестал понимать, что вы не понимаете. Решите задачу, так как вы сами её понимаете. Наверное это будет самым разумным подходом. Я всегда готов оказать посильную помощь, задавайте любые вопросы.
Правильно ли я понимаю, что именно этот подход, вызывает затруднение?
Вы это называете проверяемостью?
Я перестал понимать ход ваших мыслей. О каких индексах и о каких рамках вы говорите? Сделайте простой сортированный список на GUID-ах и О'кей. Но вы утверждаете, что проблема в скорости. Хорошо, предложите другой подход. Я повторяю — решение этой проблемы мне неизвестно.
При подготовке тестовых данных, я исхожу из того, что результат должен быть проверяем.
Объясняю. Индекс для сортировки не поможет, так как ресурсы, требуемые для запроса-вывода, значительно превышают ресурсы любого мыслимого сервера.
Строить индекс или нет для обеспечения простого несортированного запроса на таком объёме данных? Не буду вводить вас в заблуждение — этот вопрос требует изучения.
Браво! Вы меня не перестаёте удивлять! Я честно признался, что красивое решение мне неизвестно. Вы, совершенно добровольно, взялись за задачу (от которой я вас отговаривал), сами сформировали требования (против которых я всего лишь не стал возражать), но задача оказалась не постой (так бывает). Не понимаю, какой ответ вы от меня ожидаете получить? Я повторяю — мне красивого и технологичного решения этой задачи неизвестно (я её конечно же продумывал).
Пока, возникли проблемы с простой сортировкой списка. Пока не получается найти решения. Это можно «записать в книжечку». По-моему это очень хороший «сухой остаток» и потраченное время нельзя назвать «бессмысленно потраченным».
Меня устроят любые. Всё, что я делаю — задаю (очень) простые вопросы, а решения по вашей разработке (на которую вы совершенно добровольно согласились) конечно должны принимать вы.
Вопрос, конечно, не технический, а организационный. Но я бы не стал ходить к начальнику, если, конечно, это не ваш близкий родственник или хороший знакомый. В такой ситуации, приоритет контракта с Заказчиком и наличие мотивированного ПМ-а в этом контракте, для любого начальника, на порядок (или два) выше личного недовольства, пусть даже гениального, разработчика. А ПМ-то чем виноват? В 99% он в той-же шкуре, что и разработчик.
Поясните, как это? ORDER BY GUID_ID по таблице в миллиард записей? Как вам удаётся такие индексы строить?
Я вовсе не соглашался, я просто переубеждать вас не стал. Вы так уверенно взялись за задачу. А вдруг? Зачем же прерывать полёт творческой мысли.
Давайте проводить честный эксперимент и начнём с тех проблем, которые могут возникнуть в реальной жизни (ну пусть немножко виртуальной).
Я думаю, что было-бы интереснее и правильнее использовать подход, когда для каждого муравья есть ячейка и, некоторые муравьи, могут жить в нескольких ячейках (то есть список связей больше количества муравьёв). Проверить функциональность алгоритма на «бездомных муравьёв» можно даже просто ручным удалением записей на малых данных, а на больших данных смысла проверять нету.
Интересно посмотреть на ПМИ, где прописано, что зависимости получаются случайным образом и не проверяются (где вы таких Заказчиков находите?).
Кроме того, любые требования ТЗ, ПМИ, рабочий план-график и т.д. всегда можно «уточнить». Разве вам не знакома ситуация, когда завтра/на следующей неделе должна сдаваться система,
но к вам подходит ПМ и ставит в известность, что с Заказчиком подписаны «небольшие» изменения, «не влияющие на сроки», которые надо срочно доработать. Иначе контракт закрывается, нет финальной оплаты, прощай премия.
Я считаю, что задача, фактически, состоит из двух этапов:
1. Подготовка тестовых данных;
2. Подготовка результата;
Вы поторопились приступить ко второму, не разобравшись с первым.
А первый этап (подготовка результатов) уже начинает преподносить свои сюрпризы. Оказывается расчитывать на последовательность данных (препроцессинг) не стоит. Скорее наоборот — препроцессинг невозможен. Или привидите пример, как вы собираетесь выгружать отсортированные данные такого объёма из, например, СУРБД?
Я вообще не понимаю, зачем вам нужно здесь случайное распределение.
Объясняю. Муравьёв — 1000, ячеек — 1000, связей — 1000. Муравьёв типа 255 — 373. В результате — 40 записей. Вы сдаёте систему. Ни один приёмщик вам акты не подпишет.
Хорошо, вы утверждаете, что таким образом (используя ненастоящие GUID-ы) имитируете препроцессинг «я не зря спрашивал, разрешен ли препроцессинг». Что вам мешает на этапе генерации провести этот «препроцессинг» на основе «честных» GUID-ов (конечно это немного усложнит генератор).
Вы меня удивляете. Я, например, не вижу абсолютно никакой разницы между понятиями «ненастоящие GUID-ы» и «Важно, чтобы последовательность была неубывающей». Это — «подтасованные данные».
Неужели вас может интересовать результат, полученный на «подтасованных данных»?
Это понятно (посмотрел код), данные для таблицы связи формируются случайным образом. Но отлаживать функциональную часть удобнее и правильнее на небольшом объёме целостных данных.
Если для парсера важно, чтобы GUID-ы были «ненастоящими» и последовательными — такое условие нарушает «чистоту» эксперимента.
GUID-ы, которые на самом деле GUID-ами не являются, в природе не существуют, а если существуют, то это можно рассматривать как «информационное преступление».
Всего муравьёв типа 255 в файле ants — 373 (а не 273)
В 6 файлах из 35 — по 2 записи (в остальных по одной)
Не понимаю, вы можете пояснить в чём удобство? (По коду я не понял, а комментарии отсутствуют)
Пока 1000. Я устанавливал разные типы (например 255) — результат — всегда одна запись на один файл.
Всего муравьёв типа 255 в файле ants — 273
Файлов на выходе — 35 (area-004, area-009, area-013,… area-218, area-230, area-238)
Это вид консоли:
С:\anthill-guid>AntHeap.Parser.exe .\ .\ 255
Parsing ants of type 255 from .\ to .\
Parsing complete in 00:00.038