Обработка очень больших списков объектов без подкачки страниц? - PullRequest
2 голосов
/ 23 апреля 2010

У меня есть класс, который может содержать много маленьких элементов в списке.Похоже:

public class Farm {

    private ArrayList<Horse> mHorses;
}

просто интересно, что произойдет, если массив mHorses вырастет до чего-то безумного, как 15 000 элементов.Я предполагаю, что пытаться писать и читать это из хранилища данных было бы сумасшествием, потому что я был бы убит в процессе сериализации.

Важно, чтобы я мог получить весь массив за один снимок без подкачки,и у каждого элемента Horse могут быть только два строковых свойства, поэтому они довольно легкие:

public class Horse {
    private String mId;
    private String mName;
}

Мне не нужны эти лошади, проиндексированные вообще.Разумно ли просто хранить массив mHorse в виде необработанного текстового поля и заставлять моих клиентов выполнять десериализацию?Что-то вроде:

public class Farm {
    private Text mHorsesSerialized;
}

тогда, когда клиент получает экземпляр Farm, он должен взять необработанную строку лошадей и разделить ее, чтобы заново составить список, что-то вроде:

// GWT client perhaps
Farm farm = rpcCall.getMyFarm();
String horsesSerialized = farm.getHorses();
String[] horseBlocks = horsesSerialized.split(",");
for (int i = 0; i < horseBlocks.length; i++) {
    // .. continue deserializing the individual objects ...
}

ага ...

так что, надеюсь, будет быстро прочитать экземпляр фермы из хранилища данных, а клиент сериализации заплатит штраф,

Спасибо

Ответы [ 2 ]

0 голосов
/ 23 апреля 2010

Другое соображение, которое вы, возможно, захотите принять во внимание, - это то, что вы будете делать один большой запрос от GWT и, вероятно, использовать ответ на этот запрос для создания своего рода пользовательского интерфейса из 15 000 лошадей.

Это не будет быстрым, и пока он тратит время на создание списка лошадей, остальная часть пользовательского интерфейса будет в значительной степени непригодна для использования.

И более того, пользовательский интерфейс будет почти невозможен для навигации, как только он отобразится. Для чего этот интерфейс? Список лошадей, так что можно выбрать? Хотели бы вы просеять 15 000 записей, чтобы найти ту, которая им нравится?

Нумерация страниц - это не только способ уменьшить нагрузку на сервер, но и способ уменьшить нагрузку на браузер и пользователя.

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

0 голосов
/ 23 апреля 2010

Как правило, не рекомендуется использовать списки, если ваши списки не короткие (здесь это не так!) Или если их не нужно индексировать (здесь тоже не так). Вам также нужно помнить, что максимальный размер для сериализованного объекта составляет 1 МБ, поэтому любой используемый вами механизм сериализации должен помещать 15 000 записей списка в 1 МБ.

Если они подходят, то да, использование вашей собственной сериализации в поле Blob (не в текстовом поле, если вы не используете текстовый формат, такой как JSON) - ваш лучший вариант.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...