Сетка данных JavaScript для миллионов строк [закрыто]

StackOverflow https://stackoverflow.com/questions/2402953

Вопрос

Мне нужно представить большое количество строк данных (т.миллионы строк) пользователю в сетке с помощью JavaScript.

Пользователь не должен видеть страницы или просматривать только ограниченные объемы данных одновременно.

Скорее всего, должно показаться, что все данные доступны.

Вместо загрузки всех данных сразу, небольшие фрагменты загружаются по мере того, как пользователь обращается к ним (т.пролистывая сетку).

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

Какие сетки данных, написанные на JavaScript, существуют для такого плавного разбиения по страницам?

Это было полезно?

Решение

(Отказ от ответственности:Я автор SlickGrid)

ОБНОВЛЯТЬСейчас это реализовано в СликГрид.

Пожалуйста, посмотри http://github.com/mleibman/SlickGrid/issues#issue/22 за продолжающееся обсуждение того, как заставить SlickGrid работать с большим количеством строк.

Проблема в том, что SlickGrid не виртуализирует саму полосу прокрутки — высота прокручиваемой области устанавливается равной общей высоте всех строк.Строки по-прежнему добавляются и удаляются по мере прокрутки пользователем, но сама прокрутка выполняется браузером.Это позволяет ему работать очень быстро и плавно (события при прокрутке, как известно, медленны).Предостережение заключается в том, что в CSS-движках браузеров есть ошибки/ограничения, которые ограничивают потенциальную высоту элемента.Для IE это 0x123456 или 1193046 пикселей.Для других браузеров он выше.

В ветке «largenum-fix» есть экспериментальный обходной путь, который значительно увеличивает этот предел, заполняя прокручиваемую область «страницами», установленными на высоту 1 миллион пикселей, а затем используя относительное позиционирование внутри этих страниц.Поскольку ограничение высоты в движке CSS кажется другим и значительно ниже, чем в реальном движке макета, это дает нам гораздо более высокий верхний предел.

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

Рюдигер, можешь подробнее рассказать, как ты это решил?

Другие советы

https://github.com/mleibman/SlickGrid/wiki

"SlickGrid использует виртуальный рендеринг, позволяющий вам легко работать с сотнями тысяч элементов без какого-либо снижения производительности.На самом деле, нет никакой разницы в производительности между работой с сеткой из 10 строк и 100 000 строк."

Некоторые основные моменты:

  • Адаптивная виртуальная прокрутка (обрабатывает сотни тысяч строк)
  • Чрезвычайно высокая скорость рендеринга
  • Фоновый пост-рендеринг для более богатых ячеек
  • Настраиваемый и настраиваемый
  • Полная навигация с клавиатуры
  • Изменить размер столбца /изменить порядок /показать/скрыть
  • Автоматический размер колонки и принудительная подгонка
  • Подключаемые устройства форматирования ячеек и редакторы
  • Поддержка редактирования и создания новых строк." с помощью млейбман

Это бесплатно (лицензия MIT).Он использует jQuery.

Лучшие сетки, на мой взгляд, приведены ниже:

Мои лучшие три варианта — jqGrid, jqxGrid и DataTables.Они могут работать с тысячами строк и поддерживать виртуализацию.

Я не хочу разжигать пламенную войну, но, если предположить, что ваши исследователи — люди, вы не знаете их так хорошо, как думаете.Просто потому, что они иметь петабайты данных не делают их способными просматривать даже миллионы записей каким-либо осмысленным образом.Они могли бы сказать, что они хотеть увидеть миллионы записей, но это просто глупо.Пусть ваши самые умные исследователи проведут базовую математику:Предположим, они тратят 1 секунду на просмотр каждой записи.При таких темпах это займет 1 000 000 секунд, что составит более шести недель (40-часовых рабочих недель без перерывов на еду и туалет).

Неужели они (или вы) серьезно думают, что один человек (тот, кто смотрит на сетку) может добиться такой концентрации?Действительно ли они успевают сделать много за эту секунду или же (что более вероятно) отфильтровывают то, что не хотеть?Я подозреваю, что после просмотра подмножества «разумного размера» они могли бы описать вам фильтр, который автоматически отфильтровывал бы эти записи.

Как также подразумевали paxdiablo, Sleeper Smith и Lasse V Karlsen, вы (и они) не продумали требования.С другой стороны, теперь, когда вы нашли SlickGrid, я уверен, что необходимость в этих фильтрах сразу стала очевидной.

Я могу с достаточной уверенностью сказать, что вам серьезно не нужно показывать пользователю миллионы строк данных.

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

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

Я рекомендую Ext JS Grid с функцией буферизованного просмотра.

http://www.extjs.com/deploy/dev/examples/grid/buffer.html

dojox.grid.DataGrid предлагает абстракцию JS для данных, поэтому вы можете подключить ее к различным бэкэндам с помощью имеющихся хранилищ dojo.data или написать свои собственные.Вам, очевидно, понадобится тот, который поддерживает произвольный доступ для такого количества записей.DataGrid также обеспечивает полную доступность.

Отредактируйте, вот ссылка на Статья Мэтью Рассела это должно предоставить вам необходимый пример просмотра миллионов записей с помощью dojox.grid.Обратите внимание, что он использует старую версию сетки, но концепции те же, есть только некоторые несовместимые улучшения API.

О, и это совершенно бесплатно с открытым исходным кодом.

(Отказ от ответственности:Я автор w2ui)

Недавно я написал статью о том, как реализовать сетку JavaScript с 1 миллионом записей (http://w2ui.com/web/blog/7/JavaScript-Grid-with-One-Million-Records).Я обнаружил, что в конечном итоге есть 3 ограничения, которые не позволяют подняться выше:

  1. Высота div имеет ограничение (можно преодолеть виртуальной прокруткой)
  2. Такие операции, как сортировка и поиск, начинают замедляться после 1 миллиона записей или около того.
  3. ОЗУ ограничено, поскольку данные хранятся в массиве JavaScript.

Я протестировал сетку с 1 миллионом записей (кроме IE), и она работает хорошо.См. статью для демонстраций и примеров.

я использовал Плагин jQuery Grid, это было классно.

Демо

Вот несколько оптимизаций, которые вы можете применить, чтобы ускорить работу.Просто мысли вслух.

Поскольку количество строк может исчисляться миллионами, вам понадобится система кэширования только для данных JSON с сервера.Я не могу себе представить, чтобы кто-то захотел загрузить все X миллионов объектов, но если бы они это сделали, это было бы проблемой.Этот маленький тест в Chrome для массива из более чем 20 миллионов целых чисел постоянно происходит сбой на моей машине.

var data = [];
for(var i = 0; i < 20000000; i++) {
    data.push(i);
}
console.log(data.length);​

Вы могли бы использовать ЛРУ или какой-либо другой алгоритм кэширования и иметь верхнюю границу объема данных, которые вы готовы кэшировать.

Что касается самих ячеек таблицы, я думаю, что создание/уничтожение узлов DOM может быть дорогостоящим.Вместо этого вы можете просто заранее определить количество ячеек X, и всякий раз, когда пользователь прокручивает страницу до новой позиции, вставлять данные JSON в эти ячейки.Полоса прокрутки практически не будет иметь прямого отношения к тому, сколько места (высота) требуется для представления всего набора данных.Вы можете произвольно установить высоту контейнера таблицы, скажем, 5000 пикселей, и сопоставить ее с общим количеством строк.Например, если высота контейнеров составляет 5000 пикселей и общее количество строк составляет 10 миллионов, то starting row ≈ (scroll.top/5000) * 10M где scroll.top представляет расстояние прокрутки от верхней части контейнера. Небольшое демо здесь.

Чтобы определить, когда запрашивать дополнительные данные, в идеале объект должен действовать как посредник, который прослушивает события прокрутки.Этот объект отслеживает, насколько быстро пользователь прокручивает страницу, и когда кажется, что пользователь замедляется или полностью остановился, делает запрос данных для соответствующих строк.Получение данных таким способом означает, что ваши данные будут фрагментированы, поэтому кэш следует проектировать с учетом этого.

Также важную роль могут сыграть ограничения браузера на максимальное количество исходящих соединений.Пользователь может прокрутить до определенной позиции, которая вызовет запрос AJAX, но до того, как это завершится, пользователь может прокрутить до какой-либо другой части.Если сервер недостаточно отзывчив, запросы будут поставлены в очередь, и приложение будет выглядеть не отвечающим.Вы можете использовать диспетчер запросов, через который маршрутизируются все запросы, и он может отменять ожидающие запросы, чтобы освободить место.

Я знаю, что это старый вопрос, но все же..А также есть dhtmlxGrid который может обрабатывать миллионы строк.Есть демо-версия с 50 000 строк но количество строк, которые можно загрузить/обработать в сетке, не ограничено.

Отказ от ответственности:Я из команды DHTMLX.

Отказ от ответственности:я тяжело использовать Таблица данных YUI без головной боли в течение длительного времени.Он мощный и стабильный.Для ваших нужд вы можете использовать Таблица прокрутки данных который поддерживает

  • x-прокрутка
  • прокрутка по оси Y
  • XY-прокрутка
  • Мощный механизм событий

Я думаю, вам нужно то, что вам нужно, это таблицаScrollEvent.Его API говорит

Вызывается, когда в DataTable с фиксированной прокруткой имеется прокрутка.

Поскольку каждая таблица данных использует источник данных, вы можете отслеживать его данные через tableScrollEvent вместе с размером цикла рендеринга чтобы заполнить таблицу ScrollingDataTable в соответствии с вашими потребностями.

Размер цикла рендеринга говорит

В тех случаях, когда вашему DataTable необходимо отображать весь очень большой набор данных, Конфигурация renderLoopSize может помочь управлять рендерингом DOM браузера, чтобы поток пользовательского интерфейса не блокировался на очень больших таблицах..Любое значение больше 0 приведет к выполнению рендеринга DOM в цепочках setTimeout(), которые визуализируют указанное количество строк в каждом цикле.Идеальное значение должно определяться для каждой реализации, поскольку не существует жестких правил, а только общие рекомендации:

  • По умолчанию renderLoopSize равен 0, поэтому все строки отображаются в одном цикле.renderLoopSize > 0 добавляет накладные расходы, поэтому используйте его обдуманно.
  • Если ваш набор данных достаточно велик (количество строк X количество столбцов X сложность форматирования), что пользователи испытывают задержку при визуальном рендеринге и/или это приводит к зависанию скрипта, рассмотрите возможность установки renderLoopSize.
  • renderLoopSize меньше 50, вероятно, того не стоит.renderLoopSize > 100, вероятно, лучше.
  • Набор данных, вероятно, не считается достаточно большим, если он не содержит сотен и сотен строк.
  • Наличие строк renderLoopSize > 0 и < total приводит к тому, что таблица отображается в одном цикле (так же, как renderLoopSize = 0), но это также запускает такие функции, как чередование строк после рендеринга, которые обрабатываются из отдельного потока setTimeout.

Например

// Render 100 rows per loop
 var dt = new YAHOO.widget.DataTable(<WHICH_DIV_WILL_STORE_YOUR_DATATABLE>, <HOW YOUR_TABLE_IS STRUCTURED>, <WHERE_DOES_THE_DATA_COME_FROM>, {
     renderLoopSize:100
 });

<WHERE_DOES_THE_DATA_COME_FROM> — это всего лишь один Источник данных.Это может быть JSON, JSFunction, XML и даже один элемент HTML.

Здесь вы можете посмотреть Простое руководство, предоставленное мной.Будьте в курсе никакой другой Плагин DATA_TABLE поддерживает одиночный и двойной клик одновременно.YUI DataTable позволяет вам.И более, вы можете использовать его даже с JQuery без головной боли

Некоторые примеры вы можете увидеть

Не стесняйтесь спрашивать обо всем, что вы хотите о YUI DataTable.

с уважением,

Я как бы не понимаю смысла: для jqGrid вы можете использовать функцию виртуальной прокрутки:

http://www.trirand.net/aspnetmvc/grid/ Performancevirtualscrolling

но опять же, можно выполнить миллионы строк с фильтрацией:

http://www.trirand.net/aspnetmvc/grid/ Performancelinq

Хотя я действительно не понимаю смысла фразы «как будто страниц нет», я имею в виду...невозможно отобразить в браузере 1 000 000 строк одновременно — это 10 МБ HTML-сырца, я как бы не понимаю, почему пользователи не хотят видеть страницы.

В любом случае...

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

Я очень рекомендую Открытое Рико.Вначале это сложно реализовать, но как только вы поймете это, вы никогда не оглянетесь назад.

Я знаю, что этому вопросу уже несколько лет, но теперь jqgrid поддерживает виртуальную прокрутку:

http://www.trirand.com/blog/phpjqgrid/examples/paging/scrollbar/default.php

но с отключенной нумерацией страниц

Я предлагаю сигма-сетку, сигма-сетка имеет встроенные функции разбиения на страницы, которые могут поддерживать миллионы строк.Кроме того, для этого вам может понадобиться удаленный пейджинг.посмотреть демоhttp://www.sigmawidgets.com/products/sigma_grid2/demos/example_master_details.html

Взгляните на dGrid:

https://dgrid.io/

Я согласен, что пользователям НИКОГДА, НИКОГДА не понадобится просматривать миллионы строк данных одновременно, но dGrid может отображать их быстро (по экрану за раз).

Не кипятите океан, чтобы приготовить чашку чая.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top