JavaScript в таблице миллионы строк [закрыт]

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

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

некоторые моменты:

• адаптивная виртуальная прокрутка (обрабатывать сотни тысяч строки)
• очень быстрая скорость рендеринга
• фоновый пост-рендеринг для более богатых ячеек
• настраиваемые
• полная навигация с помощью клавиатуры
• изменить размер столбца / изменить порядок / Показать / Скрыть
• автоматическое изменение размеров столбца & сил-подходит
• подключаемые модули форматирования ячейки & Редакторы
• поддержка редактирования и создания новых строк." на 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-1mil-rows

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

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

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

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

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

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

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

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

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

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

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

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

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

недавно я написал статью о том, как реализовать JavaScript grid с 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 для массива на 20M + целые числа постоянно падает на моей машине.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

не кипятить океан, чтобы сделать чашку чая.