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

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

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

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

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

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

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

• Flexigrid: http://flexigrid.info/
• jQuery Grid: http://www.trirand.com/blog/
• jqGridView: http://plugins.jquery.com/project/jqGridView
• jqxGrid: http://www.jqwidgets.com/
• Ингрид: http://reconstrukt.com/ingrid/
• SlickGrid http://github.com/mleibman/SlickGrid
• DataTables http://www.datatables.net/index
• ShieldUI http://demos.shieldui.com/web/grid-virtualization/performance-1milrows

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

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

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

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

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

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

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

Я рекомендую Ext JS Grid с функцией Buffered View.

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

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

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

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

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

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

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

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

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

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

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

Так как количество строк может быть в миллионах, вам понадобится система кэширования только для данных 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, но до этого пользователь может выполнить прокрутку к какой-либо другой части. Если сервер недостаточно чувствителен, запросы будут стоять в очереди, и приложение будет выглядеть невосприимчивым. Вы можете использовать диспетчер запросов, через который маршрутизируются все запросы, и он может отменить ожидающие запросы, чтобы освободить место.

Я использовал jQuery Grid Plugin, это было приятно.

Демос

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

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

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

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

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

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

Я предлагаю вам прочитать это

http://www.sitepen.com/blog/2008/11/21/effective-use-of-jsonreststore-referencing-lazy-loading-and-more/

Отказ от ответственности: я тяжело использовать 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.

С уважением,

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

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

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

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

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

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

http://dojofoundation.org/packages/dgrid/

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

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

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