Как работать с большим объемом данных (2М записей) на UI?

Есть внутрения система для работы с большим объемом данных.

Нужно дать возможность пользователям быстро просматривать эти данные через веб интерфейс.

Упрощенно это выглядит так:

1. есть таблица в MySQL/Percona (2М записей, 350М данных)

2. есть локальный веб сервер, который должен эти данные передавать на UI

3. UI должен эти данные отображать в виде таблички, по которой можно сортировать, фильтровать, пагинация и т.д.



Напрашиваются следующие варианты реализации:



1. Загружать данные только для одной страницы через ajax при смене страницы, сортировке или фильтра

Результат: всё работает медлено из-за сортировки и фильтров по не индексируемым полям.



2 (текущий). Загружать сразу все данные и сортировать/фильтровать на стороне клиента.

Результат: если скорость сортировки и фильтрации более-менее приемлемая, то вот скорость начально загрузки данных огорчает.



Вопросы:

1. Как можно быстро загрузить 300М данных на UI?

Сейчас это несколько ajax-запросов, которые возвращают максимально компактный json.

Преобразование данных в json происходит через PHP, что конечно сказывается на производительности.

Есть ли возможность в javascript загрузить csv (select in file) и проитерировать его?

Есть ли возможность загрузить файл с json данными >75Mb? При большем объеме мой Chrome крешится.



2. Как хранить/сортировать такой объем данных на UI?

Сейчас они просто в массиве хранятся и сортируются через underscore.

Пробовал sqlite — гораздо медленее.



Примечания:

1. Браузер — Chrome. Поддержка остальных не нужна :)

2. Сервер: PHP 5.3.8/Apache2/Percona 5.1/FreeBSD

3. Таких таблиц много



Заранее спасибо за советы.
  • Вопрос задан
  • 7538 просмотров
Пригласить эксперта
Ответы на вопрос 5
@Vampiro
в 999 случаях из 1000 человек не может ничего сделать глядя на 2кк строк. Наш мозг просто не в состоянии оперировать такими объемами сразу. Треть пользователей накладывает нужный фильтр, еще треть делает сортировку по одному значимому для них столбцу, и «мотает» до нужных значений. Остальные пользуются поиском на каждую запись.

Посмотрите к какой трети относятся ваши пользователи. Мне кажется сделать диалог-мастер с фильтром гораздо проще, чем выкабениваться с 2кк записей, 90% которых не требуются пользователю :)

Если у вас данные не лезут в json, как вариант, можно делать дамп таблички в static-file, загружать его, а потом уже ajax-ом доводить до кондиции с бд, если база не часто обновляет записи.
Ответ написан
@1nd1go
1. Грузите «бочками» — по частям. Первый запрос выдает ответ с, допустим, количеством партиций и адресом откуда каждую скачивать. далее с помощью например webworker выкачивать их параллельно.

2. Т.к. sqllite deprecated, я бы попробовал IndexedDB.
Ответ написан
pxx
@pxx
Результат: всё работает медлено из-за сортировки и фильтров по не индексируемым полям.

Так индексируйте таблицы, 2кк записей — это не много для MySQL.
Как правильно сказал Vampiro, нет абсолютно никакого смысла вываливать всё на клиент, пользователь не увидит и 5% этих данных, но производительность браузера это убьет насмерть.
Ответ написан
Methos
@Methos
Для уменьшения объёма файлов (данных) вместо json можете попробовать использовать массив массивов. Первый элемент массива — ключи. Дальше — данные. Загружаете и распаковываете в объекты.

При этом методе и создание json на сервере будет быстрее — можно использовать обычные массивы и implode.
Ответ написан
freeek
@freeek
А пробовали какие-нибудь велосипеды типа jqGrid, как они с такими объёмами справляются?
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы
29 мар. 2024, в 15:28
10000 руб./за проект
29 мар. 2024, в 15:11
50000 руб./за проект
29 мар. 2024, в 15:06
50000 руб./за проект