การให้บริการฐานผู้ใช้ขนาดใหญ่ด้วยข้อมูลที่เชื่อถือได้ สม่ำเสมอ และเวลาแฝงต่ำเป็นความท้าทายที่ยากมากสำหรับทีมแบ็คเอนด์ ที่บัญชีแยกประเภท เราได้เลือกเชิงกลยุทธ์ในการโฮสต์บริการข้อมูลหลักบล็อกเชนของเราเอง โดยไม่พึ่งพาบุคคลที่สาม เราสามารถจัดการข้อมูลของลูกค้าได้ด้วยตนเอง เพื่อให้มั่นใจว่ากระบวนการพื้นฐานเป็นไปตามหลักเกณฑ์ด้านความปลอดภัยและวัตถุประสงค์ระดับบริการที่มุ่งเน้นประสิทธิภาพ (SLO)
แต่กลยุทธ์นี้ก็นำมาซึ่งความท้าทายเช่นกัน
ความท้าทายแรกของเราคือการย้ายบริการหลักที่ให้บริการข้อมูลเหล่านี้ออกจากเครื่องมือ noSQL ที่เจ๋งและเงางาม ในบทความนี้ ฉันจะเจาะลึกว่าทำไมเราถึงทำการตัดสินใจที่ยากลำบาก ความซับซ้อนที่เราพบ และผลประโยชน์ที่เราได้รับ
เป้าหมายของบทความนี้คือการแสดงแง่มุมทางเทคนิคที่ทำให้เราเลือก PostgreSQL เป็นเลเยอร์พื้นที่เก็บข้อมูลพื้นฐานใหม่สำหรับข้อมูลบล็อกเชน
ดำดิ่งสู่ข้อมูล Blockchain
ข้อมูล Blockchain มีคุณสมบัติหลักหลายประการ
ประการแรก มันเติบโตขึ้นเรื่อย ๆ และไม่มีอะไรถูกลบออกจากมัน อย่างไรก็ตาม ในทางปฏิบัติ แม้ว่าบล็อกเชนส่วนใหญ่จะเปลี่ยนแปลงไม่ได้ แต่ส่วนที่อายุน้อยที่สุดของบล็อกเชนอาจเปลี่ยนแปลงได้เนื่องจากข้อขัดแย้งที่ต้องแก้ไข เนื่องจากเครือข่ายเป็นเครือข่ายแบบเพียร์ทูเพียร์ การบล็อกที่ถูกกฎหมายหลายบล็อกอาจอยู่ร่วมกันชั่วคราว โดยปกติแล้ว สิ่งที่เก่ากว่าจะถูกลบออกไป ส่งผลให้เกิดสิ่งที่เราเรียกว่าการปรับโครงสร้างองค์กร เรื่องสั้นสั้นๆ ข้อมูลจะถูกแบ่งระหว่างหางเย็นที่ไม่เปลี่ยนรูปและสถานะส่วนหัวที่ไม่ค่อยเปลี่ยนแปลง
ปัญหาที่เรากำลังพยายามแก้ไขคือแม้ว่าบล็อกเชนจะดีสำหรับการมีข้อมูลไบเซนไทน์ที่ทนทานต่อความผิดพลาด แต่พวกมันมีประสิทธิภาพน้อยกว่าในการหั่นและหั่นเป็นลูกเต๋าในหลายแกน กล่าวคือ การรับรายการการดำเนินการที่ส่งผลกระทบต่อบัญชีนั้นเป็นเรื่องยากมาก แม้แต่การรับยอดเงินในบัญชีบนบล็อกเชนเช่น bitcoin ก็เป็นเรื่องที่ท้าทายเมื่อคุณไม่มีรายการธุรกรรม
เพื่อเอาชนะความท้าทายเหล่านี้ Ledger Explorer Services จะจัดทำดัชนีบล็อกเชนทั้งหมด ซึ่งเป็นบริการขนาดใหญ่ที่สำคัญและมีความสำคัญต่อประสิทธิภาพซึ่งเขียนขึ้นอย่างสมบูรณ์ใน Scala โดยใช้ ผลกระทบของแมว รันไทม์ประสิทธิภาพสูง เรามี bitcoin มากกว่า 10 rps ในขณะที่ยังคงรักษาเวลาแฝง p95 ให้ต่ำกว่า 100ms เรายังรับสมัคร .
ประวัติเล็กน้อย
ในตอนต้นของเรื่องราวของเรา ก่อนที่ฉันจะเข้าร่วมบริษัท ชั้นบริการข้อมูลบัญชีแยกประเภทได้รับการจัดการโดยฐานข้อมูล Neo4j ที่ฝังอยู่ ช่องที่ให้บริการแต่ละช่องจัดทำดัชนีข้อมูลของตนเองและให้บริการภายในเครื่อง ซึ่งทำให้เกิดปัญหามากมาย
ไม่รับประกันความสอดคล้องของข้อมูลระหว่างอินสแตนซ์ และขนาดที่แท้จริงของสถานะที่จำเป็นต้องจัดทำดัชนี ซึ่งรวมโดยดิสก์ neo4j และการใช้ RAM นั้นไม่สามารถปรับขนาดได้ ปัญหานี้ยิ่งแย่ลงเมื่อบริษัทเติบโตขึ้น ทำให้การสร้างอินสแตนซ์ใหม่มีความท้าทายมากขึ้นเรื่อยๆ
คาสซานดรา จากนั้นได้รับเลือกให้เป็นตัวขับเคลื่อนหลักของการตั้งค่าใหม่นี้: เป็นฐานข้อมูลแบบคลัสเตอร์ที่ปรับขนาดตามแนวนอนได้ซึ่งอยู่ด้าน AP ของทฤษฎีบท CAP ช่วยแก้ปัญหาที่เกี่ยวข้องกับการแบ่งปันข้อมูลและช่วยให้สามารถแยกระหว่างการจัดทำดัชนี ส่วนประกอบการรับรู้ของบล็อกเชน และเซิร์ฟเวอร์ API ที่ไม่มีส่วนหัวได้อย่างชัดเจน
แต่อะไรคือประเด็นของการมีสถานะทางประวัติศาสตร์ทั้งหมดหากเราไม่ได้อ่านจากมันจริง ๆ ?
ในกรณีการใช้งานของเรา ข้อมูลดิบในอดีตนั้นไม่ค่อยมีความจำเป็น เนื่องจากสถานะบัญชีผู้ใช้ของเราสามารถรวบรวมได้จากข้อมูลดังกล่าว สิ่งนี้ทำให้เราท้าทายโซลูชันการจัดเก็บข้อมูลที่มีอยู่ซึ่งใช้ฐานข้อมูลแบบกระจายของ Cassandra
ปริมาณข้อมูลที่เราต้องการจัดเก็บต่อบล็อกเชน แม้ว่าจะอยู่ในระดับเทราไบต์ แต่ก็ไม่ใช่สิ่งที่เรียกว่า “ข้อมูลขนาดใหญ่” ยิ่งกว่านั้น ส่วนของ if ที่จะใช้ตอบคำถามส่วนใหญ่ (หรือที่รู้จักว่า เส้นทางยอดนิยม) ยังมีขนาดเล็กกว่า ทุกวันนี้ เราสามารถค้นหาเซิร์ฟเวอร์ฮาร์ดแวร์สินค้าโภคภัณฑ์ที่มีที่เก็บข้อมูล NVMe SSD มากกว่า 16TB ได้อย่างง่ายดาย การปรับขนาดแนวตั้งเป็นเครื่องมือที่ทรงพลังมาก และฐานข้อมูลเชิงสัมพันธ์ก็เช่นกัน
สุดท้ายนี้ ปัญหาหลักที่เรามีกับการติดตั้ง Cassandra ในปัจจุบันไม่ใช่ทั้งโมเดลพื้นที่เก็บข้อมูลที่สิ้นเปลืองหรือกรณีการใช้ข้อมูลที่ไม่ลงตัว แต่ขาดความเป็นมิตรต่อนักพัฒนา การพัฒนาฟีเจอร์ใหม่ที่ใช้ข้อมูลบน Cassandra ได้รับการพิสูจน์แล้วว่าใช้เวลานานโดยไม่จำเป็น เราพยายามใช้แต่ละแกนใหม่ที่เราจำเป็นต้องให้ข้อมูล
ด้วยความเชี่ยวชาญของทีมเราในด้านทักษะการสร้างแบบจำลองข้อมูลและความสามารถด้าน SQL PostgreSQL เป็นผู้สมัครที่สมบูรณ์แบบ โซลูชันนี้ผ่านการทดสอบในสมรภูมิ แข็งแกร่ง ขยายได้ง่าย ทำให้เป็นตัวเลือกที่เหมาะสมที่สุด
ทำไมเราเลือก SQL มากกว่า NoSQL:
- อ่าน / เขียนยอดคงเหลือ: กรณีการใช้ข้อมูล blockchain มีความคลาดเคลื่อนอย่างมากจากการอ่านมากกว่าการเขียน (blockchain เขียนข้อมูลน้อยมากในอัตราที่สมเหตุสมผล แม้แต่สำหรับ blockchain เช่น Polygon) แคสแซนดรามีความสามารถในการดูดซับการเขียนในปริมาณที่สูงมาก ที่จริงแล้วเส้นทางการอ่านคือ อีกต่อไป กว่าเส้นทางการเขียน
- การสนับสนุนการจัดทำดัชนี: ดัชนีเป็นส่วนประกอบสำคัญของ DBMS เพื่อตอบคำถามและกรณีหรือโอกาสทางธุรกิจใหม่ๆ Cassandra รองรับการจัดทำดัชนีอย่างจำกัด ดัชนีจะมีผลเฉพาะเมื่อแบบสอบถามระบุวิธีการยับยั้งพาร์ติชันที่จะเรียกใช้แบบสอบถาม เราจ่ายที่นี่เป็นค่าใช้จ่ายในการมี กระจายโดยพลการ ฐานข้อมูล การสนับสนุน PostgreSQL สำหรับดัชนีนั้นมีประสิทธิภาพ ขยายได้ และอยู่ที่ขอบ
- การสนับสนุนการรวม: กรณีเดียวกันสำหรับการรวม; เนื่องจาก Cassandra ไม่อนุญาตให้มีการรวมหลายพาร์ติชันและไม่ยอมให้ GROUP BY clause ในภาษาเคียวรี การสนับสนุนจึงขาดไป PostgreSQL เสนอการสนับสนุนการรวมที่กว้างขวาง แม้แต่ในประเภทข้อมูลที่แปลกใหม่ เช่น ช่วงและ jsonb blobs
- การสร้างแบบจำลองข้อมูล: Cassandra มีข้อ จำกัด อย่างมากในการสร้างแบบจำลองข้อมูลที่เป็นไปได้ ต้องสร้างตารางสำหรับเกือบทุกคำขอที่คุณต้องการตอบ และข้อมูลต้องถูกทำให้เป็นบรรทัดขนาดใหญ่ (โดยใช้ เก็บคอลัมน์กว้าง แง่มุมของ C * และความจริงที่ว่านักเขียนมีราคาถูก) PostgreSQL ช่วยให้เราสามารถใช้ประโยชน์จากแง่มุมเชิงสัมพันธ์ของบล็อกเชน (การโทร ธุรกรรม บล็อก) และพื้นที่ว่างในดิสก์ ส่งเสริมการนำข้อมูลกลับมาใช้ใหม่
- แบบสอบถามเฉพาะกิจและการตรวจสอบ: การที่สามารถใช้ SQL มาตรฐานเต็มรูปแบบและทำการสืบค้นตามอำเภอใจได้ หมายความว่าเราสามารถสำรวจและค้นหาสาเหตุของข้อบกพร่องที่อาจเกิดขึ้นหรือมีข้อมูลเชิงสำรวจสำหรับกรณีการใช้งานในอนาคต เราสามารถใช้ฐานข้อมูลเป็นเครื่องมือแบบโต้ตอบและชาญฉลาด แทนที่จะเป็นที่เก็บข้อมูลโง่ๆ การทำเช่นนั้นบน Cassandra โดยไม่มีคลัสเตอร์การประมวลผลการวิเคราะห์ที่กว้างขวางและมีค่าใช้จ่ายสูง เช่น Presto, Spark เป็นต้น (และในขณะที่เรากำลังทำงานบนเซิร์ฟเวอร์แบบ Bare Metal เราไม่สามารถเข้าถึงเครื่องมือวิเคราะห์ข้อมูลแบบกระจายเช่น EMR ได้อย่างง่ายดาย)
- การใช้การจัดเก็บข้อมูล: ข้อสันนิษฐานของ Cassandra คือที่เก็บข้อมูลมีราคาถูกมากและสามารถขยายคลัสเตอร์ได้อย่างง่ายดายด้วยเครื่องใหม่ นั่นหมายความว่า ข้อจำกัดทั้งหมดของทั้งดัชนีและการรวมจะต้องชำระด้วยพื้นที่จัดเก็บ. ไม่มีดัชนีที่มีประสิทธิภาพทั่วโลกและการเข้าร่วมการสนับสนุน หมายความว่าเราต้องทำให้เป็นปกติและจัดเก็บสำเนาของตารางทั้งหมดสำหรับแต่ละแกนที่เราต้องการค้นหา PostgreSQL สำรองพื้นที่เก็บข้อมูลไว้ให้เราหลายเทราไบต์
- ความมั่นคง: เนื่องจาก Cassandra เป็นฐานข้อมูลแบบกระจาย มุ่งเน้นที่ AP (การสื่อสารทำด้วยการซุบซิบกันระหว่างโหนด) ความสอดคล้องจึงเป็นเพียงในแง่ของการเขียนเท่านั้น คุณสามารถปรับนโยบายความสอดคล้องของแต่ละคำสั่งสำหรับทั้งการอ่านและการเขียน แต่เป้าหมายของฐานข้อมูลนี้ไม่เคยมีความสอดคล้องกันมากนัก PostgreSQL มีเรื่องราวที่แข็งแกร่งในการใช้งานสำหรับภารกิจที่สำคัญและมีความยืดหยุ่นสูง การรวมศูนย์ยังหมายความว่าไม่มีเครือข่ายที่เกี่ยวข้องในเส้นทางการเขียน
- ธุรกรรมและ MVCC:
- การทำธุรกรรม: รองรับ Cassandra ธุรกรรมที่มีน้ำหนักเบาเท่านั้น ในแบบสอบถาม DML สามารถใช้การแบทช์บางรายการได้ (doc) แต่มีข้อแม้มากมาย กล่าวคือ แถวต้องอยู่ในเซิร์ฟเวอร์เดียวกัน (= พาร์ติชั่น) เพื่อไม่ให้มีประสิทธิภาพที่น่ากลัว
- MVCC: Cassandra รองรับการประทับเวลาแถว แต่ไม่รับประกัน MVCC แบบเต็ม การบดอัดสามารถลบข้อมูลเก่าและไม่มีวิธีที่จะบอก C* ว่าไม่ควรทำ (เช่น ธุรกรรมใน PG)
- PostgreSQL รองรับโมเดล MVCC ที่แข็งแกร่งซึ่งรับประกันเส้นทางการอ่านที่สอดคล้องกันสำหรับผู้ใช้ของเรา
- การขับรถ: PostgreSQL มีเครื่องมืออีกมากมายที่ใช้กันอย่างแพร่หลายเพื่อใช้งานฐานข้อมูลได้อย่างง่ายดาย นอกจากนี้เครื่องมือเช่น ฟลายเวย์ ทำให้แน่ใจว่าเรารักษาเวอร์ชันของสคีมาฐานข้อมูลที่แข็งแกร่ง เราได้รวมเข้ากับรหัสฐานของเราเรียบร้อยแล้ว ไม่มีความเป็นผู้ใหญ่ในระดับนี้เทียบเท่ากับคาสซานดรา
- ความยืดหยุ่นในแนวนอน: นี่คือจุดขายสำคัญของ Cassandra เพียงเพิ่มเครื่องจักรมากขึ้นเมื่อข้อมูลของคุณขยายตัว ไม่เทียบเท่ากับ PostgreSQL เนื่องจากต้องทำการแบ่งส่วนย่อยและแบ่งพาร์ติชันด้วยตนเอง
เราวางแผนที่จะปรับขนาดอย่างไร
อย่างที่เราได้เห็น ข้อเสียเพียงอย่างเดียวของการใช้การตั้งค่า Postgres คือการปรับขยายทั้งการอ่านและการจัดเก็บ เราจะทำอย่างไรเพื่อเอาชนะข้อจำกัดนี้
เครื่องมือที่มีประสิทธิภาพอย่างแรกที่เรามีคือการแยกทุกโปรโตคอลหรือบล็อกเชนที่เรารองรับออกเป็นฐานข้อมูลของมันเอง ซึ่งสามารถปรับขนาดได้อย่างเหมาะสมตามปริมาณและทราฟฟิก การแบ่งกลุ่มตามโดเมนธุรกิจช่วยให้มั่นใจถึงการปรับสเกลชั้นแรก
ด้วยการนำแนวคิดนี้ไปใช้เพิ่มเติม เรายังสามารถแบ่งส่วนข้อมูลที่เย็นและเป็นประวัติออกเป็นพาร์ติชันชั่วคราวได้อีกด้วย Postgres เวอร์ชันล่าสุดได้ปรับปรุงความสามารถในการใช้งานของตารางที่แบ่งพาร์ติชันขึ้นมาก ซึ่งสามารถช่วยให้สามารถย้ายข้อมูลได้อย่างราบรื่นทั่วทั้งคลัสเตอร์ของเครื่อง ตัวอย่างเช่น เราสามารถใช้เครื่องราคาถูกที่มีกำลังประมวลผลน้อยกว่าเพื่อโฮสต์ข้อมูลประวัติส่วนใหญ่ ในขณะที่เก็บพฤติกรรมที่อัดแน่นด้วย RAM ที่ให้บริการผู้ใช้จำนวนมากเพื่อโฮสต์ตารางรวมและการดำเนินการล่าสุดของผู้ใช้
วิธีการนี้ใช้ได้ผลดีมากในกรณีการใช้งานของเรา เนื่องจากไม่มีคีย์ต่างประเทศข้ามพาร์ติชันในที่เก็บข้อมูลประวัติ (ท้ายที่สุดแล้วทุกอย่างจะถูกแนบไปกับบล็อก) จากมุมมองของเซิร์ฟเวอร์หลัก ข้อมูลประวัติสามารถเข้าถึงได้อย่างโปร่งใสโดยใช้การแบ่งพาร์ติชันและส่วนขยาย postgres_fdw
เพื่อช่วยให้สิ่งเหล่านี้เข้าที่ เราได้พิจารณาส่วนขยาย TimescaleDB ด้วย ส่วนขยายนี้เพิ่มฟังก์ชันการทำงานมากมายให้กับ baseline postgres และส่วนใหญ่เหล่านี้เหมาะอย่างยิ่งสำหรับกรณีการใช้งานของเรา:
- การแบ่งตารางโดยอัตโนมัติตามเวลาเช่นคอลัมน์ (ในกรณีของเรา เราปรับโดยใช้ความสูงของบล็อกเชนเป็นข้อมูลอ้างอิง)
- อัตโนมัติ รับรู้ประเภทข้อมูลและการบีบอัดตามคอลัมน์ของอันที่เก่ากว่า สิ่งนี้ทำให้มั่นใจได้ว่าอัตราส่วนการบีบอัดเกือบจะสมบูรณ์แบบโดยใช้อัลกอริธึมที่ทันสมัยกับข้อมูลที่คล้ายกันมาก
- การรวมตามถังเวลาที่มีประสิทธิภาพเพื่อคำนวณยอดคงเหลือย้อนหลังและกราฟข้อมูลตลาดได้อย่างง่ายดาย
เราเพิ่งอยู่ในช่วงเริ่มต้นของการทดลองเกี่ยวกับพื้นที่เก็บข้อมูล และนี่จะเป็นการปลดล็อกกรณีการใช้งานจำนวนมาก การพิสูจน์แนวคิดโดยใช้ข้อมูลจำนวนเล็กน้อย (~10k บล็อกบน ethereum mainnet ดังนั้นข้อมูลประมาณ 2 วัน) แสดงการลดพื้นที่ดิสก์สูงถึง 40%.
อย่างที่เราได้เห็น ปริมาณข้อมูล ถ้าเราใช้กลยุทธ์ที่เหมาะสม ก็ไม่เป็นปัญหา แต่จะปรับขนาดตามขนาดฐานผู้ใช้ของเราได้อย่างไร?
เรามีข้อได้เปรียบที่ดีอยู่แล้ว: เราจัดทำดัชนีข้อมูลบล็อกเชนทั้งหมด ดังนั้นพื้นที่เก็บข้อมูลที่ต้องการจะไม่เพิ่มขึ้นเหมือนจำนวนผู้ใช้ แต่เท่ากับขนาดบล็อกเชนทั้งหมด การเพิ่มประสิทธิภาพการจัดเก็บและการอ่านเป็นแบบตั้งฉากโดยสิ้นเชิงในความละเอียด
การตั้งค่านี้เมื่อรวมกับความต้องการในการเขียนที่ต่ำมากตามสัดส่วนของปริมาณการอ่านที่ต้องให้บริการ คือการตั้งค่าในฝันสำหรับรูปแบบแบบจำลองการจัดกลุ่มผู้นำ-ผู้ติดตาม เพื่อเพิ่มประสิทธิภาพและทรูพุตเพิ่มเติม เรายังสามารถวางตัวจำลองการอ่านของ postgres บนเครื่องเดียวกันกับเซิร์ฟเวอร์ API และใช้ประโยชน์จากซ็อกเก็ตโดเมน UNIX เพื่อข้ามการรับส่งเครือข่าย
นี่คือตัวอย่างของกลยุทธ์การจำลองข้อมูลที่เราสามารถใช้เพื่อปรับขนาดการอ่านของเรา กล่องสีเทาอ่อนแสดงถึงเซิร์ฟเวอร์เดียว เราจะเห็นว่าพ็อด API นั้นอยู่ในตำแหน่งเดียวกับสำเนาของข้อมูลที่ร้อนที่สุดโดยตรง เพื่อให้แน่ใจว่าเวลาถ่ายโอนระหว่างที่เก็บข้อมูลและผู้ใช้จะน้อยที่สุด ตัวอย่างการเก็บถาวรที่อธิบายไว้ก่อนหน้านี้ไม่ได้แสดงเพื่อไม่ให้สคีมาซับซ้อนเกินไป
สรุปข้อสังเกต
ในฐานะผู้ใช้ Cassandra ในระยะยาว ฉันต้องการเน้นย้ำว่านี่เป็นฐานข้อมูลที่ยอดเยี่ยมในการออกแบบ ซึ่งเหมาะกับแอปพลิเคชันที่หลากหลาย น่าเสียดายที่ตัวเลือกที่ทำขึ้นที่ Ledger เพื่อใช้งานนั้นทำมาจากกรณีการใช้ข้อมูลซึ่งไม่เคยเกิดขึ้นจริง
ประสิทธิภาพการทำงานของทีมของเราได้รับผลกระทบ และตั้งหน้าตั้งตารอความท้าทายที่เราต้องแก้ไข เราเลือกที่จะกัดกระสุนและไม่ตกหลุมพรางต้นทุนที่ตกต่ำ
ในหลายกรณี ข้อมูลของคุณไม่ใช่ข้อมูลขนาดใหญ่ การจัดการการกระจายข้อมูลไม่ใช่เรื่องยากในกรณีส่วนใหญ่ และการแลกเปลี่ยนฐานข้อมูลแบบกระจายที่สมบูรณ์จำเป็นต้องได้รับการพิจารณาอย่างรอบคอบ สิ่งสำคัญที่ต้องพิจารณาคือประสบการณ์ของนักพัฒนาเนื่องจากช่วยประหยัดเวลาอันมีค่าในการสร้างสิ่งอื่น นี่คือกรณีการใช้งานจริงที่เราต้องลงทุนอย่างมาก
- เนื้อหาที่ขับเคลื่อนด้วย SEO และการเผยแพร่ประชาสัมพันธ์ รับการขยายวันนี้
- เพลโตไอสตรีม. ข้อมูลอัจฉริยะ Web3 ขยายความรู้ เข้าถึงได้ที่นี่.
- การสร้างอนาคตโดย Adryenn Ashley เข้าถึงได้ที่นี่.
- ซื้อและขายหุ้นในบริษัท PRE-IPO ด้วย PREIPO® เข้าถึงได้ที่นี่.
- ที่มา: https://www.ledger.com/blog/serving-web3-at-web2-scale
- :มี
- :เป็น
- :ไม่
- $ ขึ้น
- 10
- 10K
- 20
- a
- ความสามารถ
- สามารถ
- เข้า
- Accessed
- ลงชื่อเข้าใช้
- ข้าม
- จริง
- ปรับ
- เพิ่ม
- เพิ่ม
- เป็นไปตาม
- ความได้เปรียบ
- การรวมตัว
- อัลกอริทึม
- ทั้งหมด
- อนุญาต
- ช่วยให้
- แล้ว
- ด้วย
- แม้ว่า
- จำนวน
- an
- การวิเคราะห์
- การวิเคราะห์
- และ
- คำตอบ
- ใด
- สิ่งใด
- API
- การใช้งาน
- ประยุกต์
- เข้าใกล้
- อย่างเหมาะสม
- เอกสารเก่า
- เป็น
- รอบ
- ศิลปะ
- บทความ
- AS
- แง่มุม
- ด้าน
- ข้อสมมติ
- At
- ใช้ได้
- ทราบ
- ไป
- แกน
- แกน
- แบ็กเอนด์
- ยอดคงเหลือ
- ยอดคงเหลือ
- ฐาน
- ตาม
- baseline
- BE
- เพราะ
- รับ
- ก่อน
- การเริ่มต้น
- เบฮีมอธ
- กำลัง
- ประโยชน์ที่ได้รับ
- ระหว่าง
- ใหญ่
- ข้อมูลขนาดใหญ่
- บิต
- Bitcoin
- ปิดกั้น
- blockchain
- ข้อมูล blockchain
- blockchains
- Blocks
- ทั้งสอง
- กล่อง
- ในกล่องสี่เหลี่ยม
- นำ
- Bug
- สร้าง
- ธุรกิจ
- แต่
- by
- โทรศัพท์
- โทร
- CAN
- ผู้สมัคร
- ฝาครอบ
- รอบคอบ
- กรณี
- กรณี
- ก่อให้เกิด
- ที่เกิดจาก
- ส่วนกลาง
- โซ่
- ท้าทาย
- ความท้าทาย
- ท้าทาย
- เปลี่ยนแปลง
- เปลี่ยนแปลง
- ถูก
- ราคาถูก
- เครื่องถูกกว่า
- ทางเลือก
- Choose
- เลือก
- เลือก
- ชัดเจน
- Cluster
- รหัส
- ฐานรหัส
- ผู้สมัครที่ไม่รู้จัก
- คอลัมน์
- รวม
- สินค้า
- การสื่อสาร
- บริษัท
- ความซับซ้อน
- ส่วนประกอบ
- คำนวณ
- แนวคิด
- แนวความคิด
- การพิจารณา
- ถือว่า
- คงเส้นคงวา
- เย็น
- แกน
- ราคา
- ได้
- ที่สร้างขึ้น
- วิกฤติ
- ปัจจุบัน
- ข้อมูล
- การวิเคราะห์ข้อมูล
- การแชร์ข้อมูล
- การจัดเก็บข้อมูล
- ฐานข้อมูล
- วัน
- การตัดสินใจ
- อธิบาย
- ออกแบบ
- ผู้พัฒนา
- ที่กำลังพัฒนา
- ยาก
- โดยตรง
- ฝุ่น
- กระจาย
- การกระจาย
- แบ่งออก
- do
- ทำ
- การทำ
- โดเมน
- Dont
- ข้อเสีย
- ฝัน
- คนขับรถ
- สอง
- e
- แต่ละ
- อย่างง่ายดาย
- ง่าย
- ขอบ
- มีประสิทธิภาพ
- ที่มีประสิทธิภาพ
- อื่น
- ที่ฝัง
- เน้น
- ทำให้สามารถ
- ให้กำลังใจ
- เสริม
- ทำให้มั่นใจ
- เพื่อให้แน่ใจ
- การสร้างความมั่นใจ
- เท่ากัน
- ฯลฯ
- ethereum
- ethereum เมนเน็ต
- แม้
- ในที่สุด
- เคย
- ทุกๆ
- ทุกอย่าง
- ตัวอย่าง
- ที่มีอยู่
- แปลกใหม่
- ขยาย
- ประสบการณ์
- ความชำนาญ
- สำรวจ
- นักสำรวจ
- ขยายออก
- นามสกุล
- กว้างขวาง
- ความจริง
- ตก
- ลักษณะ
- คุณสมบัติ
- สองสาม
- หา
- ชื่อจริง
- พอดี
- สำหรับ
- ต่างประเทศ
- ข้างหน้า
- ความเป็นมิตร
- ราคาเริ่มต้นที่
- เต็ม
- เต็มที่
- อย่างเต็มที่
- ฟังก์ชันการทำงาน
- ต่อไป
- อนาคต
- ได้รับ
- กำหนด
- ทั่วโลก
- เป้าหมาย
- ไป
- กราฟ
- สีเทา
- ยิ่งใหญ่
- บัญชีกลุ่ม
- ขึ้น
- การเจริญเติบโต
- รับประกัน
- แนวทาง
- มี
- ยาก
- ฮาร์ดแวร์
- มี
- มี
- หัว
- หนัก
- ความสูง
- ช่วย
- โปรดคลิกที่นี่เพื่ออ่านรายละเอียดเพิ่มเติม
- จุดสูง
- อย่างสูง
- ทางประวัติศาสตร์
- เจ้าภาพ
- ร้อน
- ที่ร้อนแรงที่สุด
- สรุป ความน่าเชื่อถือของ Olymp Trade?
- ทำอย่างไร
- อย่างไรก็ตาม
- HTML
- HTTPS
- i
- ในอุดมคติ
- if
- ไม่เปลี่ยนรูป
- ที่กระทบ
- การดำเนินการ
- การปรับปรุง
- in
- ขึ้น
- ดัชนี
- ดัชนี
- ตัวอย่าง
- แบบบูรณาการ
- การโต้ตอบ
- เข้าไป
- ลงทุน
- ร่วมมือ
- ปัญหา
- ปัญหา
- IT
- ITS
- ร่วม
- เข้าร่วม
- jpg
- เพียงแค่
- การเก็บรักษา
- คีย์
- กุญแจ
- ชนิด
- ไม่มี
- ภาษา
- ใหญ่
- ความแอบแฝง
- ล่าสุด
- ชั้น
- นำ
- บัญชีแยกประเภท
- ถูกกฎหมาย
- น้อยลง
- ชั้น
- เลฟเวอเรจ
- เบา
- มีน้ำหนักเบา
- กดไลก์
- การ จำกัด
- ข้อ จำกัด
- ถูก จำกัด
- รายการ
- น้อย
- ในท้องถิ่น
- นาน
- มอง
- ที่ต้องการหา
- Lot
- ต่ำ
- เครื่อง
- ทำ
- หลัก
- เมนเน็ต
- เก็บรักษา
- ส่วนใหญ่
- การทำ
- จัดการ
- การจัดการ
- ด้วยมือ
- หลาย
- ตลาด
- ข้อมูลการตลาด
- วุฒิภาวะ
- ความกว้างสูงสุด
- อาจ..
- วิธี
- โลหะ
- อพยพ
- ต่ำสุด
- ภารกิจ
- แบบ
- การสร้างแบบจำลอง
- ข้อมูลเพิ่มเติม
- ยิ่งไปกว่านั้น
- มากที่สุด
- ย้าย
- มาก
- ต้อง
- คือ
- เกือบทั้งหมด
- จำเป็นต้อง
- จำเป็น
- ความต้องการ
- ค่า
- เครือข่าย
- ไม่เคย
- ใหม่
- ดี
- ไม่
- โหนด
- ไม่มีอะไร
- จำนวน
- มากมาย
- วัตถุประสงค์
- of
- on
- ONE
- เพียง
- ทำงาน
- การดำเนินการ
- โอกาส
- or
- ใบสั่ง
- ของเรา
- ตัวเรา
- เกิน
- เอาชนะ
- ของตนเอง
- ต้องจ่าย
- ส่วนหนึ่ง
- คู่กรณี
- เส้นทาง
- แบบแผน
- ชำระ
- ลูกแพร์
- เพื่อนเพื่อเพื่อน
- สมบูรณ์
- การปฏิบัติ
- มุมมอง
- สถานที่
- แผนการ
- เพลโต
- เพลโตดาต้าอินเทลลิเจนซ์
- เพลโตดาต้า
- ฝัก
- จุด
- นโยบาย
- รูปหลายเหลี่ยม
- เป็นไปได้
- postgresql
- ที่มีศักยภาพ
- อำนาจ
- ที่มีประสิทธิภาพ
- การปฏิบัติ
- ปัญหา
- กระบวนการ
- ผลผลิต
- พิสูจน์
- สัดส่วน
- เสนอ
- โปรโตคอล
- ที่พิสูจน์แล้ว
- ให้
- ให้
- ใส่
- คำสั่ง
- แรม
- พิสัย
- คะแนน
- ค่อนข้าง
- อัตราส่วน
- ดิบ
- อ่าน
- จริง
- จริงๆ
- เหมาะสม
- การลดลง
- เกี่ยวกับ
- ที่เกี่ยวข้อง
- น่าเชื่อถือ
- การปฏิรูป
- แบบจำลอง
- การทำซ้ำ
- แสดง
- เป็นตัวแทนของ
- ขอ
- ยืดหยุ่น
- ความละเอียด
- ได้รับการแก้ไข
- ส่งผลให้
- นำมาใช้ใหม่
- ขวา
- แข็งแรง
- ราก
- ปัดเศษ
- แถว
- วิ่ง
- วิ่ง
- เดียวกัน
- สกาล่า
- ที่ปรับขนาดได้
- ขนาด
- ปรับ
- ได้อย่างลงตัว
- ค้นหา
- ความปลอดภัย
- เห็น
- เห็น
- ส่วน
- การแบ่งส่วน
- Selling
- จุดขาย
- บริการ
- บริการ
- การให้บริการ
- ชุด
- การติดตั้ง
- หลาย
- ชาร์ดดิ้ง
- ใช้งานร่วมกัน
- สั้น
- โชว์
- ด้าน
- คล้ายคลึงกัน
- ตั้งแต่
- เดียว
- ขนาด
- ทักษะ
- เล็ก
- มีขนาดเล็กกว่า
- สมาร์ท
- So
- ทางออก
- แก้
- แก้ปัญหา
- บาง
- ช่องว่าง
- จุดประกาย
- วางไข่
- SQL
- มาตรฐาน
- สถานะ
- คำแถลง
- การเก็บรักษา
- จัดเก็บ
- เรื่องราว
- ยุทธศาสตร์
- กลยุทธ์
- แข็งแรง
- เสถียร
- ประสบความสำเร็จ
- สนับสนุน
- รองรับ
- ตาราง
- เอา
- การ
- งาน
- ทีม
- วิชาการ
- บอก
- เงื่อนไขการใช้บริการ
- กว่า
- ที่
- พื้นที่
- บล็อก
- รัฐ
- ของพวกเขา
- แล้วก็
- ที่นั่น
- ล้อยางขัดเหล่านี้ติดตั้งบนแกน XNUMX (มม.) ผลิตภัณฑ์นี้ถูกผลิตในหลายรูปทรง และหลากหลายเบอร์ความแน่นหนาของปริมาณอนุภาคขัดของมัน จะทำให้ท่านได้รับประสิทธิภาพสูงในการขัดและการใช้งานที่ยาวนาน
- พวกเขา
- ที่สาม
- บุคคลที่สาม
- นี้
- ปริมาณงาน
- เวลา
- ไปยัง
- เกินไป
- เครื่องมือ
- เครื่องมือ
- รวม
- โดยสิ้นเชิง
- การจราจร
- การทำธุกรรม
- การทำธุรกรรม
- โอน
- โปร่งใส
- ชนิด
- ชนิด
- ในที่สุด
- ภายใต้
- พื้นฐาน
- น่าเสียดาย
- ยูนิกซ์
- ปลดล็อค
- เกินความจำเป็น
- us
- การใช้งาน
- การใช้
- ใช้
- ใช้กรณี
- มือสอง
- ผู้ใช้งาน
- ผู้ใช้
- การใช้
- มักจะ
- มีคุณค่า
- ความหลากหลาย
- แนวตั้ง
- มาก
- ปริมาณ
- ต้องการ
- คือ
- ทาง..
- we
- Web2
- Web3
- ดี
- อะไร
- ความหมายของ
- เมื่อ
- ที่
- ในขณะที่
- ในขณะที่
- ทั้งหมด
- ทำไม
- กว้าง
- อย่างกว้างขวาง
- จะ
- กับ
- ไม่มี
- โรงงาน
- เขียน
- เขียน
- เธอ
- สุดท้อง
- ของคุณ
- ลมทะเล