<del id="nnjnj"></del><track id="nnjnj"></track>

<p id="nnjnj"></p>

<address id="nnjnj"></address>

    <pre id="nnjnj"><pre id="nnjnj"></pre></pre>

      <noframes id="nnjnj"><ruby id="nnjnj"><ruby id="nnjnj"></ruby></ruby>

      • 自動秒收錄
      • 軟件:1973
      • 資訊:57811|
      • 收錄網站:279872|

      IT精英團

      JD.COM面試問題:ElasticSearch深度分頁解決方案

      JD.COM面試問題:ElasticSearch深度分頁解決方案

      瀏覽次數:
      評論次數:
      編輯: 景同
      信息來源: ITPUB
      更新日期: 2022-05-05 15:32:28
      摘要

      以下文章來源于月伴飛魚,作者日常加油站前言Elasticsearch是一個實時的分布式搜索與分析引擎,在使用過程中,有一些典型的使用場景,比如分頁、遍歷等。在使用關系型數據庫中,我們被告知要注意甚至

      • 正文開始
      • 相關閱讀
      • 推薦作品

      以下文章來源于月伴飛魚,作者日常加油站

      Elasticsearch是一個實時分布式搜索和分析引擎。在使用的過程中,有一些典型的使用場景,比如分頁、遍歷等。

      在關系數據庫的使用中,我們被告知要注意甚至明確禁止深度分頁的使用。同樣,在Elasticsearch中,也要盡量避免使用深度分頁。

      本文主要介紹Elasticsearch中分頁相關的內容!

      From/Size參數

      在ES中,缺省情況下,分頁查詢返回前10個匹配的命中結果。

      如果需要分頁,您需要使用from和size參數。

      from參數定義了要跳過的命中次數,默認為0;

      size參數定義需要返回的最大命中數。

      基本的ES查詢語句如下所示:

      帖子/我的索引/我的類型/_搜索

      {

      查詢' :{'match_all':{},

      從:100開始,

      尺寸' :10

      }

      上面的查詢表示從搜索結果的第100項開始的10條數據。

      「那么,這個查詢語句在ES集群內部是怎么執行的呢?」

      在ES中,搜索一般包括兩個階段,查詢階段和提取階段,可以簡單理解。查詢階段確定獲取哪個文檔,獲取階段獲取特定的文檔。

      查詢階段

      如上圖所示,描述了搜索請求的查詢階段:

      客戶端發送搜索請求,節點1接收該請求。然后,node1創建一個優先級隊列,其大小為size,用于存儲結果。我們稱節點1為協調節點。

      協調節點將請求廣播給相關的分片,每個分片在內部執行搜索請求,然后將結果存儲到與from size大小相同的內部優先級隊列中,可以理解為包含前N個結果的列表。

      每個碎片將臨時存儲在自己的優先級隊列中的數據返回給協調節點。協調節點得到各個分片返回的結果后,將結果合并一次,生成一個全局優先級隊列,存儲在自己的優先級隊列中。

      在上面的示例中,協調節點獲得(來自size) * 6條數據,然后對它們進行合并和排序,然后從size中選擇前面的數據,并將它們存儲在獲取階段的優先級隊列中。

      另外,每個切片返回給協調節點的數據用于從大小數據中選擇第一個,所以可以只返回唯一標記doc的_id和用于排序的_score,這也可以保證返回的數據量足夠小。

      在協調節點計算出自己的優先級隊列后,查詢階段結束,進入獲取階段。

      獲取階段

      查詢階段知道要獲取哪些數據,但它不獲取特定的數據,這是獲取階段需要做的事情。

      382A1.jpg">

      上圖展示了 fetch 過程:

      1. coordinating node 發送 GET 請求到相關shards。
      2. shard 根據 doc 的_id取到數據詳情,然后返回給 coordinating node。
      3. coordinating node 返回數據給 Client。

      coordinating node 的優先級隊列里有from + size_doc _id,但是,在 fetch 階段,并不需要取回所有數據,在上面的例子中,前100條數據是不需要取的,只需要取優先級隊列里的第101到110條數據即可。

      需要取的數據可能在不同分片,也可能在同一分片,coordinating node 使用 「multi-get」來避免多次去同一分片取數據,從而提高性能。

      「這種方式請求深度分頁是有問題的:」

      我們可以假設在一個有 5 個主分片的索引中搜索。當我們請求結果的第一頁(結果從 1 到 10 ),每一個分片產生前 10 的結果,并且返回給 協調節點 ,協調節點對 50 個結果排序得到全部結果的前 10 個。

      現在假設我們請求第 1000 頁—結果從 10001 到 10010 。所有都以相同的方式工作除了每個分片不得不產生前10010個結果以外。然后協調節點對全部 50050 個結果排序最后丟棄掉這些結果中的 50040 個結果。

      「對結果排序的成本隨分頁的深度成指數上升?!?/strong>

      「注意1:」

      size的大小不能超過index.max_result_window這個參數的設置,默認為10000。

      如果搜索size大于10000,需要設置index.max_result_window參數

      PUT _settings
      {
          "index": {
              "max_result_window": "10000000"
          }
      }  

      「注意2:」

      _doc將在未來的版本移除,詳見:

      • https://www.elastic.co/cn/blog/moving-from-types-to-typeless-apis-in-elasticsearch-7-0
      • https://elasticsearch.cn/article/158

      深度分頁問題

      Elasticsearch 的From/Size方式提供了分頁的功能,同時,也有相應的限制。

      舉個例子,一個索引,有10億數據,分10個 shards,然后,一個搜索請求,from=1000000,size=100,這時候,會帶來嚴重的性能問題:CPU,內存,IO,網絡帶寬。

      在 query 階段,每個shards需要返回 1000100 條數據給 coordinating node,而 coordinating node 需要接收10 * 1000,100 條數據,即使每條數據只有 _doc _id_score,這數據量也很大了?

      「在另一方面,我們意識到,這種深度分頁的請求并不合理,因為我們是很少人為的看很后面的請求的,在很多的業務場景中,都直接限制分頁,比如只能看前100頁?!?/strong>

      比如,有1千萬粉絲的微信大V,要給所有粉絲群取法消息,或者給某省粉絲發,這時候就需要取得所有符合條件的粉絲,而最容易想到的就是利用 from + size 來實現,不過,這個是不現實的,這時,可以采用 Elasticsearch 提供的其他方式來實現遍歷。

      深度分頁問題大致可以分為兩類:

      • 「隨機深度分頁:隨機跳轉頁面」
      • 「滾動深度分頁:只能一頁一頁往下查詢」

      「下面介紹幾個官方提供的深度分頁方法」

      Scroll

      ?

      Scroll遍歷數據

      ?

      我們可以把scroll理解為關系型數據庫里的cursor,因此,scroll并不適合用來做實時搜索,而更適合用于后臺批處理任務,比如群fa。

      這個分頁的用法,「不是為了實時查詢數據」,而是為了「一次性查詢大量的數據(甚至是全部的數據」)。

      因為這個scroll相當于維護了一份當前索引段的快照信息,這個快照信息是你執行這個scroll查詢時的快照。在這個查詢后的任何新索引進來的數據,都不會在這個快照中查詢到。

      但是它相對于from和size,不是查詢所有數據然后剔除不要的部分,而是記錄一個讀取的位置,保證下一次快速繼續讀取。

      不考慮排序的時候,可以結合SearchType.SCAN使用。

      scroll可以分為初始化和遍歷兩部,初始化時將「所有符合搜索條件的搜索結果緩存起來(注意,這里只是緩存的doc_id,而并不是真的緩存了所有的文檔數據,取數據是在fetch階段完成的)」,可以想象成快照。

      在遍歷時,從這個快照里取數據,也就是說,在初始化后,對索引插入、刪除、更新數據都不會影響遍歷結果。

      「基本使用」

      POST /twitter/tweet/_search?scroll=1m
      {
          "size": 100,
          "query": {
              "match" : {
                  "title" : "elasticsearch"
              }
          }
      }

      初始化指明 index 和 type,然后,加上參數 scroll,表示暫存搜索結果的時間,其它就像一個普通的search請求一樣。

      會返回一個_scroll_id,_scroll_id用來下次取數據用。

      「遍歷」

      POST /_search?scroll=1m
      {
          "scroll_id":"XXXXXXXXXXXXXXXXXXXXXXX I am scroll id XXXXXXXXXXXXXXX"
      }

      這里的scroll_id即 上一次遍歷取回的_scroll_id或者是初始化返回的_scroll_id,同樣的,需要帶 scroll 參數。

      重復這一步驟,直到返回的數據為空,即遍歷完成。

      「注意,每次都要傳參數 scroll,刷新搜索結果的緩存時間」。另外,「不需要指定 index 和 type」。

      設置scroll的時候,需要使搜索結果緩存到下一次遍歷完成,「同時,也不能太長,畢竟空間有限?!?/strong>

      「優缺點」

      缺點:

      1. 「scroll_id會占用大量的資源(特別是排序的請求)」
      2. 同樣的,scroll后接超時時間,頻繁的發起scroll請求,會出現一些列問題。
      3. 「是生成的歷史快照,對于數據的變更不會反映到快照上?!?/strong>

      「優點:」

      適用于非實時處理大量數據的情況,比如要進行數據遷移或者索引變更之類的。

      Scroll Scan

      ES提供了scroll scan方式進一步提高遍歷性能,但是scroll scan不支持排序,因此scroll scan適合不需要排序的場景

      「基本使用」

      Scroll Scan 的遍歷與普通 Scroll 一樣,初始化存在一點差別。

      POST /my_index/my_type/_search?search_type=scan&scroll=1m&size=50
      {
       "query": { "match_all": {}}
      }

      需要指明參數:

      • search_type:賦值為scan,表示采用 Scroll Scan 的方式遍歷,同時告訴 Elasticsearch 搜索結果不需要排序。
      • scroll:同上,傳時間。
      • size:與普通的 size 不同,這個 size 表示的是每個 shard 返回的 size 數,最終結果最大為 number_of_shards * size。

      「Scroll Scan與Scroll的區別」

      1. Scroll-Scan結果「沒有排序」,按index順序返回,沒有排序,可以提高取數據性能。
      2. 初始化時只返回 _scroll_id,沒有具體的hits結果
      3. size控制的是每個分片的返回的數據量,而不是整個請求返回的數據量。

      Sliced Scroll

      如果你數據量很大,用Scroll遍歷數據那確實是接受不了,現在Scroll接口可以并發來進行數據遍歷了。

      每個Scroll請求,可以分成多個Slice請求,可以理解為切片,各Slice獨立并行,比用Scroll遍歷要快很多倍。

      POST /index/type/_search?scroll=1m
      {
          "query": { "match_all": {}},
          "slice": {
              "id": ,
              "max": 5
          }   
      }
       
      POST ip:port/index/type/_search?scroll=1m
      {
          "query": { "match_all": {}},
          "slice": {
              "id": 1,
              "max": 5
          }   
      }

      上邊的示例可以單獨請求兩塊數據,最終五塊數據合并的結果與直接scroll scan相同。

      其中max是分塊數,id是第幾塊。

      ?

      官方文檔中建議max的值不要超過shard的數量,否則可能會導致內存爆炸。

      ?

      Search After

      Search_after是 ES 5 新引入的一種分頁查詢機制,其原理幾乎就是和scroll一樣,因此代碼也幾乎是一樣的。

      「基本使用:」

      第一步:

      POST twitter/_search
      {
          "size": 10,
          "query": {
              "match" : {
                  "title" : "es"
              }
          },
          "sort": [
              {"date": "asc"},
              {"_id": "desc"}
          ]
      }

      返回出的結果信息 :

      {
            "took" : 29,
            "timed_out" : false,
            "_shards" : {
              "total" : 1,
              "successful" : 1,
              "skipped" : ,
              "failed" : 
            },
            "hits" : {
              "total" : {
                "value" : 5,
                "relation" : "eq"
              },
              "max_score" : null,
              "hits" : [
                {
                  ...
                  },
                  "sort" : [
                    ...
                  ]
                },
                {
                  ...
                  },
                  "sort" : [
                    124648691,
                    "624812"
                  ]
                }
              ]
            }
          }

      上面的請求會為每一個文檔返回一個包含sort排序值的數組。

      這些sort排序值可以被用于search_after參數里以便抓取下一頁的數據。

      比如,我們可以使用最后的一個文檔的sort排序值,將它傳遞給search_after參數:

      GET twitter/_search
      {
          "size": 10,
          "query": {
              "match" : {
                  "title" : "es"
              }
          },
          "search_after": [124648691, "624812"],
          "sort": [
              {"date": "asc"},
              {"_id": "desc"}
          ]
      }

      若我們想接著上次讀取的結果進行讀取下一頁數據,第二次查詢在第一次查詢時的語句基礎上添加search_after,并指明從哪個數據后開始讀取。

      「基本原理」

      es維護一個實時游標,它以上一次查詢的最后一條記錄為游標,方便對下一頁的查詢,它是一個無狀態的查詢,因此每次查詢的都是最新的數據。

      由于它采用記錄作為游標,因此「SearchAfter要求doc中至少有一條全局唯一變量(每個文檔具有一個唯一值的字段應該用作排序規范)」

      「優缺點」

      「優點:」

      1. 無狀態查詢,可以防止在查詢過程中,數據的變更無法及時反映到查詢中。
      2. 不需要維護scroll_id,不需要維護快照,因此可以避免消耗大量的資源。

      「缺點:」

      1. 由于無狀態查詢,因此在查詢期間的變更可能會導致跨頁面的不一值。
      2. 排序順序可能會在執行期間發生變化,具體取決于索引的更新和刪除。
      3. 至少需要制定一個唯一的不重復字段來排序。
      4. 它不適用于大幅度跳頁查詢,或者全量導出,對第N頁的跳轉查詢相當于對es不斷重復的執行N次search after,而全量導出則是在短時間內執行大量的重復查詢。

      SEARCH_AFTER不是自由跳轉到任意頁面的解決方案,而是并行滾動多個查詢的解決方案。

      總結

      分頁方式性能優點缺點場景
      from + size靈活性好,實現簡單深度分頁問題數據量比較小,能容忍深度分頁問題
      scroll解決了深度分頁問題無法反應數據的實時性(快照版本)維護成本高,需要維護一個 scroll_id海量數據的導出需要查詢海量結果集的數據
      search_after性能最好不存在深度分頁問題能夠反映數據的實時變更實現復雜,需要有一個全局唯一的字段連續分頁的實現會比較復雜,因為每一次查詢都需要上次查詢的結果,它不適用于大幅度跳頁查詢海量數據的分頁

      ES7版本變更

      參照:https://www.elastic.co/guide/en/elasticsearch/reference/master/paginate-search-results.html#scroll-search-results

      7.*版本中,ES官方不再推薦使用Scroll方法來進行深分頁,而是推薦使用帶PIT的search_after來進行查詢;

      7.*版本開始,您可以使用SEARCH_AFTER參數通過上一頁中的一組排序值檢索下一頁命中。

      使用SEARCH_AFTER需要多個具有相同查詢和排序值的搜索請求。

      如果這些請求之間發生刷新,則結果的順序可能會更改,從而導致頁面之間的結果不一致。

      為防止出現這種情況,您可以創建一個時間點(PIT)來在搜索過程中保留當前索引狀態。

      POST /my-index-000001/_pit?keep_alive=1m

      返回一個PIT ID:
      {
        "id": "46ToAwMDaWR5BXV1aWQyKwZub2RlXzMAAAAAAAAAACoBYwADaWR4BXV1aWQxAgZub2RlXzEAAAAAAAAAAAEBYQADaWR5BXV1aWQyKgZub2RlXzIAAAAAAAAAAAwBYgACBXV1aWQyAAAFdXVpZDEAAQltYXRjaF9hbGw_gAAAAA=="
      }

      在搜索請求中指定PIT:

      GET /_search
      {
        "size": 10000,
        "query": {
          "match" : {
            "user.id" : "elkbee"
          }
        },
        "pit": {
           "id":  "46ToAwMDaWR5BXV1aWQyKwZub2RlXzMAAAAAAAAAACoBYwADaWR4BXV1aWQxAgZub2RlXzEAAAAAAAAAAAEBYQADaWR5BXV1aWQyKgZub2RlXzIAAAAAAAAAAAwBYgACBXV1aWQyAAAFdXVpZDEAAQltYXRjaF9hbGw_gAAAAA==", 
           "keep_alive": "1m"
        },
        "sort": [ 
          {"@timestamp": {"order": "asc", "format": "strict_date_optional_time_nanos", "numeric_type" : "date_nanos" }}
        ]
      }

      性能對比

      分別分頁獲取1 - 10,49000 - 49010,99000 - 99010范圍各10條數據(前提10w條),性能大致是這樣:

      向前翻頁

      對于向前翻頁,ES中沒有相應API,但是根據官方說法(https://github.com/elastic/elasticsearch/issues/29449),ES中的向前翻頁問題可以通過翻轉排序方式來實現即:

      1. 對于某一頁,正序search_after該頁的最后一條數據id為下一頁,則逆序search_after該頁的第一條數據id則為上一頁。
      2. 國內論壇上,有人使用緩存來解決上一頁的問題:https://elasticsearch.cn/question/7711

      總結

      1. 如果數據量?。╢rom+size在10000條內),或者只關注結果集的TopN數據,可以使用from/size 分頁,簡單粗暴
      2. 數據量大,深度翻頁,后臺批處理任務(數據遷移)之類的任務,使用 scroll 方式
      3. 數據量大,深度翻頁,用戶實時、高并發查詢需求,使用 search after 方式

      個人思考

      Scroll和search_after原理基本相同,他們都采用了游標的方式來進行深分頁。

      這種方式雖然能夠一定程度上解決深分頁問題。但是,它們并不是深分頁問題的終極解決方案,深分頁問題「必須避免!!」。

      對于Scroll,無可避免的要維護scroll_id和歷史快照,并且,還必須保證scroll_id的存活時間,這對服務器是一個巨大的負荷。

      對于Search_After,如果允許用戶大幅度跳轉頁面,會導致短時間內頻繁的搜索動作,這樣的效率非常低下,這也會增加服務器的負荷,同時,在查詢過程中,索引的增刪改會導致查詢數據不一致或者排序變化,造成結果不準確。

      Search_After本身就是一種業務折中方案,它不允許指定跳轉到頁面,而只提供下一頁的功能。

      Scroll默認你會在后續將所有符合條件的數據都取出來,所以,它只是搜索到了所有的符合條件的doc_id(這也是為什么官方推薦用doc_id進行排序,因為本身緩存的就是doc_id,如果用其他字段排序會增加查詢量),并將它們排序后保存在協調節點(coordinate node),但是并沒有將所有數據進行fetch,而是每次scroll,讀取size個文檔,并返回此次讀取的最后一個文檔以及上下文狀態,用以告知下一次需要從哪個shard的哪個文檔之后開始讀取。

      這也是為什么官方不推薦scroll用來給用戶進行實時的分頁查詢,而是適合于大批量的拉取數據,因為它從設計上就不是為了實時讀取數據而設計的。

      以下文章來源于月伴飛魚 ,作者日常加油站  

      標簽:數據 分頁 結果
      說說春云的全鏈路灰度發布方案~
      ? 上一篇 2022-05-05
      優化Docker鏡像安全性的12個技巧 建議收藏起來!
      下一篇 ? 2022-05-05
      • 如何在Ubuntu中保留文件系統并備份當前開發板鏡像
        0閱讀 0條評論 個贊
        在Ubuntu保留文件系統或者說備份當前開發板鏡像的需求在不斷增加。比如Ubuntu文件系統需要安裝庫文件的話直接使用apt-get工具就可以下載,但由于需要下載的核心板較多,比較費時間,這時需要將安……
      • 國產核心板全志T507助力消防系統升級
        0閱讀 0條評論 個贊
        9月16日下午,位于湖南長沙市區內的中國電信大樓發生火災,建筑高度218米,現場濃煙滾滾,數十層樓體燃燒劇烈。消防救援人員趕到現場后很快將火勢控制住,目前大樓火勢已被撲滅,所幸未發現人員傷亡。湖南電信……
      • 教大家如何處理Spring Boot易流中的用戶和群體!
        0閱讀 0條評論 個贊
        1.準備工作2.用戶操作2.1添加用戶2.2修改用戶2.3刪除用戶2.4查詢用戶3.組操作3.1添加組3.2修改組3.3刪除組3.4查詢組4.查看表詳情雖然說我們在實際開發中,……
      • 從PG15開始WAL壓縮優化
        0閱讀 0條評論 個贊
        PG15傳聞中的超級令人激動的功能大多數跳票了,年初我也寫過一個關于PG15新功能跳票的文章。PG15BETA已經發出幾個月了,似乎PG15里令人激動人心的功能不多,不過從長長的新功能列表里,……
      • 深入了解美團葉子發射器開源方案
        0閱讀 0條評論 個贊
        大家好,我是樹哥。之前我們有聊過「如何設計一個分布式ID發號器」,其中有講過4種解決方案,分別是:UUID類雪花算法數據庫自增主鍵Redis原子自增美團以第2、3種解決方案為基礎,開發出……
      發表評論 共有條評論
      用戶名: 密碼:
      驗證碼: 匿名發表
      • 基于aiohttp的異步爬蟲python實戰
        0閱讀 0條評論 個贊
        鋼鐵知識庫,一個學習python爬蟲、數據分析的知識庫。人生苦短,快用python。之前我們使用requests庫爬取某個站點的時候,每發出一個請求,程序必須等待網站返回響應才能接著運行,而在整個爬蟲……
      • [設計模式] Java設計模式-橋模式
        0閱讀 0條評論 個贊
        目錄【設計模式】Java設計模式-橋接模式簡介橋接模式實例代碼示例①、品牌接口②、汽車品牌③、抽象汽車類④、汽車類型子類⑤、橋接模式測試1|1簡介橋接(Bridge)是用于把抽象化與實現化解耦,使……
      • :自古以來 特工程序就是兵家必敗之地
        0閱讀 0條評論 個贊
        正向代理的血案前幾天打算使用golang做一個代理程序,golang標準庫net/http/httputil已經提供了這樣的能力。一把梭之后發現必然返回403Forbidden,我直接在targe……
      • web端pdf編輯能力的設計與實踐
        0閱讀 0條評論 個贊
        本期作者顧伊凡嗶哩嗶哩資深開發工程師2021年加入B站,負責UP主創作激勵、收益中心、電子簽約平臺前端建設。本文將從業務場景與技術實現等角度對“web端pdf編輯能力”進行基本的介紹。01背景B站電……
      • MySQL查詢性能優化指數下推的七大武器
        0閱讀 0條評論 個贊
        前面已經講了MySQL的其他查詢性能優化方式,沒看過可以去了解一下:MySQL查詢性能優化七種武器之索引潛水MySQL查詢性能優化七種武器之鏈路追蹤今天要講的是MySQL的另一種查詢性能優化方式—索……
      • 人人都能讀懂的源代碼——那些關于DOM的常見鉤子包(二)
        0閱讀 0條評論 個贊
        本文是深入淺出ahooks源碼系列文章的第十五篇,該系列已整理成文檔-地址。覺得還不錯,給個star支持一下哈,Thanks。本篇接著針對關于DOM的各個Hook封裝進行解讀。useFul……
      • 平均負載和CPU利用率有什么區別?
        2閱讀 0條評論 個贊
        大家好,我是樹哥。在性能優化中,我們經常會關注CPU平均負載這個指標。但如果讓你來跟我解釋一下什么是平均負載,你能說得清楚嗎?它跟CPU使用率有什么區別?我想可能很多人都數不清楚,今天我們就來……
      • 多線程技術的歷史發展和簡單使用
        0閱讀 0條評論 個贊
        進程與線程進程是應用的執行實例,可狹義理解為一個應用程序就是一個進程。啟用一個應用程序時就是啟動了一個進程。該應用運行所需的所有地址空間,代碼,數據及系統資源都屬于此進程。進程所使用的所有資源會在進程……
      • 深入了解春季交易:介紹 使用 原則
        8閱讀 0條評論 個贊
        大家好,我是樹哥。Spring事務是復雜一致性業務必備的知識點,掌握好Spring事務可以讓我們寫出更好地代碼。這篇文章我們將介紹Spring事務的誕生背景,從而讓我們可以更清晰地了解Sp……
      • RDD星火基金簡介(01)
        0閱讀 0條評論 個贊
        1,基本概念RDD(ResilientDistributedDataset):彈性分布式數據集它是Spark中最基本的數據抽象,是編寫Spark程序的基礎。簡單的來講,一個Spark程序可以概括……
      • MQ系列5:5的發送模式:RocketMQ消息
        0閱讀 0條評論 個贊
        在之前的篇章中,我們學習了RocketMQ的原理,以及RocketMQ中命名服務ServiceName的運行流程,本篇從消息的生產、消費來理解一條消息的生命周期。1消息生產在RocketMQ中……
      • 拓撲嶺CEO雷鵬:創業不只是技術
        0閱讀 0條評論 個贊
        云計算的出現,加速了企業信息技術的發展。數據庫是最常用的基礎軟件之一,它通常能提供計算和存儲的能力。雖然分布式數據庫也做到了很好的擴展性,但它不能算是「云原生」?!冈圃鷶祿臁沟暮诵?,是要設計一種更……
      • i.MX8MQ自制背板無PCIe問題詳解
        9閱讀 0條評論 個贊
        在飛凌嵌入式OKMX8MQ-C開發板上有兩個PCIe接口,對應著兩個PCIe差分時鐘,兩路PCIe分別用作了M.2接口卡槽KEYE(P37)和KEYM(P34)。很多使用FETMX8MQ-C核心板的用……
      • 人工智能OPS的莫拉維克悖論
        3閱讀 0條評論 個贊
        莫拉維克的悖論是人工智能和機器人研究人員觀察到,與傳統假設相反,推理需要很少的計算,但感覺運動和感知技能需要大量的計算資源。該原則由HansMoravec、RodneyBrooks、Marvin……
      • c#異步高級————通道[1]
        0閱讀 0條評論 個贊
        前言該系列為異步編程的進階篇,其實也不能這么講。世界上本沒有進階篇,只能說是高級篇(高級篇不能說多高級,是對底層的封裝的意思),只要是加深理解都是進階。本章先介紹一下channel。正文下面沒什么好說……
      • smile——Java機器學習引擎
        2閱讀 0條評論 個贊
        資源https://haifengl.github.io/https://github.com/haifengl/smile介紹Smile(統計機器智能和學習引擎)是一個基于Java和Scala的快速……
      • Linux驅動開發十六 輸入系統33543 系統附帶的輸入驅動程序
        0閱讀 0條評論 個贊
        前面兩章我們通過input子系統構建了一個按鍵類型的輸入設備的驅動,其實Linux的內核還提供了一套基于GPIO的按鍵驅動程序,和LED設備一樣,我們只需要在編譯內核的過程中進行配置然后在設備樹中定義……
      • 面試問題:Java序列化和反序列化
        0閱讀 0條評論 個贊
        目錄序列化和反序列化的概念應用場景?序列化實現的方式繼承Serializable接口,普通序列化繼承Externalizable接口,強制自定義序列化serialVersionUID的作用靜態變量不會……
      • 基于iframe的微前端框架——青田
        33閱讀 0條評論 個贊
        vivo互聯網前端團隊-JiangZuohan一、背景VAPD是一款專為團隊協作辦公場景設計的項目管理工具,實踐敏捷開發與持續交付,以「項目」為核心,融合需求、任務、缺陷等應用,使用敏捷迭代、小……
      • 大促銷活動如何抵御高流量DDoS攻擊?
        0閱讀 0條評論 個贊
        大促活動如何抵御大流量DDoS攻擊?每一次活動大促帶來的迅猛流量,對技術人而言都是一次嚴峻考驗。如果在活動期間遭受黑產惡意DDoS攻擊,無疑是雪上加霜。電商的特性是業務常態下通常不會遭受大流量DD……
      最近發布資訊
      更多
      警花高潮嗷嗷叫
      <del id="nnjnj"></del><track id="nnjnj"></track>

      <p id="nnjnj"></p>

      <address id="nnjnj"></address>

        <pre id="nnjnj"><pre id="nnjnj"></pre></pre>

          <noframes id="nnjnj"><ruby id="nnjnj"><ruby id="nnjnj"></ruby></ruby>