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

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

Демонстрации

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

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

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

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

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

Некоторые особенности:

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

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

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

Поскольку количество строк может исчисляться миллионами, вам понадобится система кэширования только для 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, и сопоставить ее с общим количеством строк. Например, если высота контейнера 5000px, а всего имеется 10M строк, то начальный ряд ≈ (scroll.top/5000) * 10M, где scroll.top представляет собой расстояние прокрутки от верха контейнера. Небольшая демонстрация здесь.

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

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

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

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

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

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

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

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

• x-scrolling
• y-scrolling
• xy-scrolling
• мощный механизм событий

Для того, что вам нужно, Я думаю, вам нужен tableScrollEvent . Его API сообщает:

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

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

Размер цикла рендеринга:

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

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

Например,

// 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
 });

- это всего лишь один источник данных . Это может быть 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 строк сразу в браузере - это 10MB HTML raw, я как бы не вижу, почему пользователи не хотят видеть страницы.

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

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

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

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

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