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

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

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

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

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

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

Какие сетки данных, написанные на JavaScript, существуют для этого типа бесшовного пейджинга?

ОТВЕТЫ

Ответ 1

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

UPDATE Это теперь реализовано в SlickGrid.

См. http://github.com/mleibman/SlickGrid/issues#issue/22 для продолжения обсуждения работы SlickGrid с большим количеством строк.

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

Существует экспериментальное обходное решение в ветке "largenum-fix", которое значительно увеличивает этот предел за счет заполнения прокручиваемой области "страницами", установленной на высоту 1 М пикселей, а затем используя относительное позиционирование в этих страницах. Поскольку предел высоты в движке CSS кажется другим и значительно ниже, чем в реальном макете, это дает нам гораздо более высокий верхний предел.

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

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

Ответ 2

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

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

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

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

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

Ответ 3

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

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

Ответ 4

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

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

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

Ответ 5

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

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

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

Ответ 7

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

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

О, и это абсолютно бесплатный открытый исходный код.

Ответ 8

(Отказ от ответственности: я являюсь автором w2ui)

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

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

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

Ответ 10

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

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

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

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

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

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

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

Ответ 11

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

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

Ответ 12

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

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

Для чего вам нужно, я думаю, что вы хотите, это tableScrollEvent. Его API говорит

Запущен, когда прокрутка DataTable имеет прокрутку.

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

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

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

  • По умолчанию renderLoopSize равно 0, поэтому все строки отображаются в одном цикле. В renderLoopSize > 0 добавляются служебные данные, поэтому используйте задумчиво.
  • Если ваш набор данных достаточно большой (количество строк X число сложности форматирования столбцов X), пользователи испытывают латентность визуального рендеринга и/или приводят к зависанию script рассмотрите настройку renderLoopSize.
  • Средство renderLoopSize до 50, вероятно, не стоит. Вероятно, рендерингLoopSize > 100 лучше.
  • Набор данных, вероятно, не считается достаточно большим, если он не содержит сотни и сотни строк.
  • Наличие renderLoopSize > 0 и < общие строки заставляют таблицу визуализироваться в одном цикле (так же, как 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 > это всего лишь один DataSource. Это может быть JSON, JSFunction, XML и даже один элемент HTML

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

В некоторых примерах вы можете увидеть

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

С уважением,

Ответ 14

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

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

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

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

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

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

Ответ 15

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

Ответ 16

Я бы очень рекомендовал Open rico. Его трудно реализовать в начале, но как только вы его схватите, вы никогда не оглядитесь назад.

Ответ 18

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

Ответ 19

Посмотрите на dGrid:

https://dgrid.io/

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

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