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

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

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

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

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

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

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

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

ОБНОВЛЕНИЕ Это теперь реализовано в SlickGrid .

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

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

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

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

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

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

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

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

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

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

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

• Флексигрид: http://flexigrid.info/
• Сетка jQuery: 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 Grid с функцией Buffered View.

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

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

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

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

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

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

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

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

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

демос

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Поскольку каждый DataTable использует DataSource, вы можете отслеживать его данные через 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> только один DataSource . Это может быть 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 может быть легко преобразован в объекты и, следовательно, строки таблицы могут быть легко ненавязчиво построены

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

Я знаю, что этому вопросу уже несколько лет, но 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 может отображать их быстро (за один раз).

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