มีวิธีใดบ้างที่ฉันสามารถใช้ที่เก็บคีย์ - ค่าสำหรับข้อมูลเชิงพื้นที่?


26

ฉันเคยใช้ฐานข้อมูลเชิงสัมพันธ์จำนวนมากในอดีต แต่ฉันได้อ่านเกี่ยวกับฐานข้อมูล NoSQL ทั้งหมดแล้วและที่เก็บคีย์ - ค่าดูเหมือนว่ามีการหยุดพัก

เมื่อฉันจัดเก็บวัตถุทางเรขาคณิตฉันส่วนใหญ่ใช้ ID คอลัมน์ที่มีการจัดทำดัชนีห้าส่วนคือ MIN_X, MAX_X, MIN_Y และ MAX_Y (โดยที่ X และ Y อยู่ในเส้นโครงแผนที่) ฉันไม่ต้องการดัชนีในข้อมูลอื่นของฉัน

ฉันต้องการค่า X และ Y เพื่อค้นหาวัตถุในสถานที่ที่ระบุ (สี่เหลี่ยมผืนผ้าแผนที่) และฉันต้องการค่า ID หากฉันต้องการอัปเดตวัตถุที่ระบุ

มีวิธีใดบ้างที่ฉันสามารถใช้ที่เก็บคีย์ - ค่าสำหรับสิ่งนี้

คำตอบ:


18

เราใช้ Google AppEngine เพื่อเรียกใช้แบบสอบถามเชิงพื้นที่ / แอตทริบิวต์และปัญหาหลัก (นับจากวันแรก) คือวิธีการจัดทำดัชนีชุดของเส้น / รูปหลายเหลี่ยมขนาดใหญ่โดยพลการ ข้อมูลชี้ไม่ยากเกินไป (ดูที่ geohash, geomodel และอื่น ๆ ) แต่ชุดของรูปหลายเหลี่ยมขนาดเล็ก / ขนาดใหญ่แบบสุ่มมักเป็นปัญหาเสมอ (และในบางกรณียังคงเป็น)

ฉันได้ลองใช้การสร้างดัชนีเชิงพื้นที่หลายรุ่นใน GAE แต่ส่วนใหญ่เป็นเพียงรูปแบบสองแบบด้านล่าง ไม่มีใครเร็วเท่ากับฐานข้อมูล SQL และทุกคนมีข้อดี / ข้อเสีย การแลกเปลี่ยนดูเหมือนจะสมเหตุสมผลสำหรับแอพการทำแผนที่บนอินเทอร์เน็ตเป็นส่วนใหญ่ นอกจากนี้ทั้งสองด้านล่างจะต้องเชื่อมโยงกับการเลือกรูปทรงเรขาคณิตในหน่วยความจำ (ผ่าน JTS และอื่น ๆ ) เพื่อลบคุณลักษณะใด ๆ ที่ไม่ตรงกับพารามิเตอร์การค้นหาขั้นสุดท้าย และในที่สุดพวกเขาก็ใช้คุณสมบัติเฉพาะของ GAE แต่ฉันแน่ใจว่ามันสามารถนำไปใช้กับสถาปัตยกรรมอื่น ๆ (หรือใช้ TyphoonAE เพื่อทำงานบนคลัสเตอร์ Linux, ec2 และอื่น ๆ )

กริด - จัดเก็บฟีเจอร์ทั้งหมดสำหรับบางพื้นที่ในดัชนีกริดที่รู้จัก วางดัชนีเชิงพื้นที่ขนาดเล็กลงบนกริดเพื่อให้คุณสำรวจชุดคุณสมบัติที่มีอยู่อย่างรวดเร็ว สำหรับข้อความค้นหาส่วนใหญ่คุณจะต้องดึงกริดจำนวนหนึ่งซึ่งรวดเร็วเนื่องจากคุณรู้แผนการตั้งชื่อกริดที่แน่นอนและความเกี่ยวข้องกับหน่วยงาน K / V (รับไม่ใช่แบบสอบถาม)

ข้อดี - เร็วสวยใช้งานง่ายไม่มีรอยเท้าหน่วยความจำ

ข้อด้อย - จำเป็นต้องมีการประมวลผลล่วงหน้าผู้ใช้จำเป็นต้องตัดสินใจขนาดของกริด, geoms ขนาดใหญ่จะถูกใช้ร่วมกันในหลายกริด, การจัดกลุ่มสามารถทำให้กริดกลายเป็นโอเวอร์โหลด, ค่าใช้จ่ายในการทำให้เป็นอนุกรม /

QuadKeys - นี่คือการใช้งานปัจจุบัน โดยพื้นฐานแล้วจะเหมือนกับกริดยกเว้นไม่มีระดับกริดที่ตั้งไว้ เมื่อมีการเพิ่มคุณสมบัติพวกมันจะถูกทำดัชนีโดยตาราง quadkey ที่มีขอบเขตทั้งหมด (หรือในบางกรณีแบ่งออกเป็นสองส่วนเมื่อไม่สามารถใช้ quadkey เดียวคิดว่าเป็นข้อมูล) หลังจากพบ qk แล้วแบ่งออกเป็นจำนวนสูงสุดของ qk ที่เล็กลงซึ่งให้การแสดงคุณลักษณะของธัญพืชที่ละเอียดยิ่งขึ้น ตัวชี้ / bbox ไปยังคุณลักษณะนั้นจะถูกบรรจุลงใน gridindex ที่มีน้ำหนักเบา (กลุ่มของคุณสมบัติ) ที่สามารถสอบถามได้ (การออกแบบดั้งเดิมสอบถามคุณสมบัติโดยตรง แต่สิ่งนี้พิสูจน์ได้ช้าเกินไป / CPU เข้มข้นในกรณีที่ resultset มีขนาดใหญ่)

Polykey Quadkeys http://www.arc2earth.com/images/help/GAE_QKS_1.png รูปหลายเหลี่ยม Quadkeys http://www.arc2earth.com/images/help/GAE_QKS_2.png

อนุสัญญาการตั้งชื่อรูปสี่เหลี่ยมที่ใช้ด้านบนเป็นที่รู้จักกันดีและที่สำคัญกว่านั้นมีแนวโน้มที่จะรักษาสถานที่ (อธิบายเพิ่มเติมที่นี่ )

รูปหลายเหลี่ยมด้านบนมีลักษณะดังนี้: 0320101013123 03201010131212 03201010131213 0320101013132 03201010131313 ... 03201010131313 031310101313123

หากขอบเขตแบบสอบถามมีขนาดเล็กเพียงพอคุณสามารถดึงข้อมูลได้โดยตรงผ่าน qk สิ่งนี้ดีที่สุดเนื่องจากมีการเรียกแบตช์ rpc เพียงครั้งเดียวไปยังที่เก็บข้อมูล GAE หากขอบเขตมีขนาดใหญ่พอที่จะรวม qks ที่เป็นไปได้มากเกินไป (> 1,000) คุณสามารถเลือกใช้ตัวกรอง (เช่น: qk> = 0320101013 และ qk <= 0320101013 + \ ufffd) หลักการตั้งชื่อ quadkey บวกกับวิธีที่ GAE จัดทำดัชนีสตริงอนุญาตให้แบบสอบถามด้านบนดึงเฉพาะกริดที่มีอยู่ซึ่งอยู่ต่ำกว่าค่า qk นั้น

มีข้อแม้อื่น ๆ และปัญหาเพอร์เฟ็กต์ แต่โดยทั่วไปแล้วความสามารถในการสอบถามเกี่ยวกับ quadkeys ที่ทำให้เป็นไปได้

ตัวอย่าง - แบบสอบถามเกี่ยวกับมณฑลของสหรัฐอเมริกา: geojson

ข้อดี - เร็วมากไม่มีการกำหนดขนาดกริดไม่มีรอยความทรงจำไม่มีกริดที่แออัด

ข้อเสีย - จำเป็นต้องมีการประมวลผลล่วงหน้าสามารถโอเวอร์โฟทได้ในบางสถานการณ์ไม่มีข้อมูลแบบโพลาร์

Space Filling Curves - ดูที่การสืบค้น NextGen ของ Alfredที่ Google I / O ในปีนี้ การรวมของเส้นโค้งการเติมพื้นที่ / เวลาทั่วไปพร้อมกับตัวดำเนินการ MultiQuery ใหม่ (ทำงานแบบขนาน) จะช่วยให้มีการสืบค้นเชิงพื้นที่ที่น่าสนใจจริงๆ มันจะเอาชนะประสิทธิภาพ SQL ดั้งเดิมได้หรือไม่ ยากที่จะพูด แต่ควรปรับขนาดได้ดีจริงๆ และเรากำลังใกล้เข้ามาอย่างรวดเร็วในอนาคตซึ่งอุปกรณ์เคลื่อนที่ที่มีรูปร่าง / ขนาดทั้งหมดจะช่วยเพิ่มอัตราการเข้าชมเว็บไซต์ / บริการของคุณ

ในที่สุดฉันก็ยอมรับว่าคุณควรตรวจสอบโดเมนปัญหาของคุณอย่างใกล้ชิดก่อนที่จะเลือก NoSQL บน SQL ในกรณีของเราฉันชอบรูปแบบการกำหนดราคาของ GAE ดังนั้นจึงไม่มีทางเลือกจริง ๆ แต่ถ้าคุณไม่ต้องการปรับขนาดประหยัดเวลาด้วยตัวคุณเองและใช้เพียง sql db มาตรฐาน


คุณพูดถึง GAE แต่คุณใช้ฐานข้อมูลใดอยู่ มีหลายวิธี: cloud.google.com/products/storage
Don McCurdy

11

ฉันเคยได้ยิน GeoCouch ซึ่งเป็นการนำ CouchDB ไปใช้สำหรับข้อมูลพื้นฐาน และฉันก็คิดว่า MongoDB มีความสามารถในการจัดทำดัชนีเชิงพื้นที่


ใช่พวกเขาทั้งสองทำได้และ SimpleGeo กำลังสร้างส่วนขยายเชิงพื้นที่ให้กับคาสซานดรา ฉันไม่เคยได้ยินอะไรเลยใน Voldemort หรือ MemCache
TheSteve0

โอ้ฉันชอบสิ่งที่ SimpleGeo กำลังทำอยู่ ฉันอิจฉาและรักที่จะทำงานเพื่อพวกเขา!
JoshFinnie

8

นี่เป็นคำถามเกี่ยวกับอัลกอริทึมเป็นหลัก Stack Overflow อาจเป็นสถานที่ที่เหมาะสำหรับการถาม

ไม่ว่าในกรณีใดคำตอบสำหรับคำถามโดยตรงของคุณคือ "ใช่คุณสามารถใช้ร้านค้า kvp เพื่อแสดงข้อมูลเชิงพื้นที่" คำถามที่ดีกว่า แต่อาจเป็น "ฉันควรใช้ที่เก็บ kvp เพื่อแสดงข้อมูลเชิงพื้นที่หรือไม่"

คำตอบของคำถามนั้น (เหมือนกับคนอื่น ๆ ) คือ "ขึ้นอยู่กับ" ขึ้นอยู่กับขนาดของคุณภาระงานของคุณ (ธุรกรรม) ลักษณะของข้อมูลและโครงสร้างพื้นฐานการคำนวณที่คุณมี

ที่เก็บ kvp จะมีค่าโสหุ้ยต่ำซึ่งสามารถช่วยเพิ่มปริมาณงานสำหรับการแทรกจำนวนมากและการอัพเดทแบบขนาน อย่างไรก็ตามมันจะไม่เป็นการค้นหาเชิงพื้นที่ที่รวดเร็ว (ค้นหาวัตถุทั้งหมดภายในสี่เหลี่ยมผืนผ้า) สำหรับสิ่งที่คุณต้องการดัชนีเชิงพื้นที่เช่น R-Tree

อย่างไรก็ตามหากคุณมีปริมาณข้อมูลที่มากและกลุ่มคอมพิวเตอร์ขนาดใหญ่การใช้ดัชนี kvp อาจให้ประโยชน์ในการทำงานบางอย่าง วิธีเดียวที่จะรู้ได้อย่างแท้จริงคือการวัดแบบสมบูรณ์โดยใช้ข้อมูลจริงและเข้าถึงเสื้อที่คุณคาดหวัง

อัปเดต :

นี่คือข้อมูลเพิ่มเติมเล็กน้อย คุณสามารถใช้ที่เก็บ KVP เพื่อทำการค้นหาเชิงพื้นที่ ปัญหาคือว่ามันช้า หากต้องการดูว่าเหตุใดพิจารณาเรื่องนี้:

  ***********
  ***********
  ***********
  ***********
  ****###****
  ****###****
  ****###****
  ***********
  ***********
  ***********
  ***********

โดยที่ * และ # เป็นตัวแทนวัตถุวางในตาราง 11x11 โดยมีจุดกำเนิดที่มุมซ้ายบน ลองนึกภาพการค้นหาวัตถุภายในสี่เหลี่ยม (4,4) - (7,7) ที่ควรจะหา "#" ทั้งหมด สมมติว่าคุณใช้ b + -tree เพื่อแสดงดัชนีของคุณในที่จัดเก็บ KVP คุณสามารถค้นหาผลลัพธ์โดยใช้ดัชนี "X" หรือดัชนี "Y" ในกรณีนี้มันไม่สำคัญว่า เพื่อการอภิปรายฉันจะใช้ดัชนี x คุณจะทำการค้นหา log (n) ในดัชนี X เพื่อค้นหาโหนดแรกที่มีค่า X เป็น "4" จากนั้นวนซ้ำโหนด b + -tree leaf node จนกว่าคุณจะพบโหนดที่มีค่ามากกว่า 7 เช่นเดียวกับคุณ วนซ้ำตามดัชนี x คุณจะปฏิเสธสิ่งที่อยู่นอกช่วง y ที่ต้องการ

นี่มันช้า ลองนึกภาพบนกริดขนาดใหญ่ที่มีความหนาแน่นเท่ากันพูด 100 K * 100 เคคุณจะต้องสแกนรายการดัชนี "300, 000" เพื่อค้นหาเพียง 9 รายการ หากคุณใช้ R-Tree ที่สมดุลอย่างเหมาะสมอย่างไรก็ตามการค้นหาดัชนีอาจต้องสแกนประมาณ 90 รายการเท่านั้น นั่นเป็นความแตกต่างอย่างมาก

อย่างไรก็ตามปัญหาคือการรักษา R-Tree ให้สมดุลนั้นมีราคาแพง นี่คือเหตุผลที่คำตอบคือ "มันขึ้นอยู่กับ" และทำไมคำถาม "ฉันควรทำสิ่งนี้" สำคัญกว่า "ฉันจะทำอย่างไร"

หากคุณแทรกและลบบันทึกจำนวนมากและส่วนใหญ่ทำการค้นหา "รหัสวัตถุ" และไม่ทำการค้นหา "เชิงพื้นที่" บ่อยครั้งการใช้ดัชนี KVP ของคุณจะให้ประสิทธิภาพที่ดีขึ้นสำหรับสิ่งที่คุณต้องการใช้ระบบ . อย่างไรก็ตามหากคุณแทรกหรือลบนาน ๆ ครั้ง แต่ทำการค้นหาเชิงพื้นที่บ่อยครั้งคุณต้องการใช้ R-Tree


ฉันจะไม่ยอมรับคำตอบเช่น "ใช่คุณทำได้" เพราะผมต้องการที่จะรู้วิธี และ "ฉันควร .. " ไม่ใช่คำถามที่ดีกว่าเพราะอย่างที่คุณพูดว่า "มันขึ้นอยู่กับ"
Jonas

1
ฉันต้องไม่เห็นด้วยกับคุณ หากคุณต้องการสร้างระบบที่มีประโยชน์หรือทิ้งการอ้างอิงที่มีประโยชน์บนอินเทอร์เน็ตสำหรับคนอื่น ๆ ที่สร้างระบบที่คล้ายกันดังนั้น "ฉันควร" มีความสำคัญมากกว่า "วิธี" เพื่อประโยชน์ในการเป็นประโยชน์ แต่ฉันได้แก้ไขคำตอบของคุณเพื่อให้ข้อมูลบางอย่างเกี่ยวกับวิธีการ
Scott Wisniewski

@ Jonas ฉันเชื่อว่าคำตอบ "คำแนะนำ" ที่คุณได้รับเป็นเพราะวิธีการที่คุณถามคำถาม: "แต่ฉันได้อ่านเกี่ยวกับฐานข้อมูล NoSQL ทั้งหมดและร้านค้า Key-Value ดูน่าสนใจ" สิ่งนี้มีจุดเด่นทั้งหมดของทางแก้ไขที่กำลังมองหาปัญหา
JasonBirch

NoSQL แก้ปัญหาได้ แต่เป็นปัญหาที่ไม่มีใครทำได้จริงเพราะมันไม่ได้ทำงานในระดับที่มากพอ น่าเสียดายที่คิดอยู่เสมอว่าระบบของเรามีขนาดใหญ่กว่าในรูปแบบที่ยิ่งใหญ่กว่าที่เป็นจริง :)
JamesRyan

4

หากคุณใช้ค่า lat / long คุณอาจสามารถใช้geohashเป็นส่วนหนึ่งของค่าในร้านค้าของคุณได้

นี่คือหนึ่งใน NYC dr5regy6rc6ye

ด้วย geohash คุณสามารถเริ่มเคาะตัวอักษรในตอนท้ายของ geohash เพื่อรับตารางความแม่นยำที่แตกต่างกัน: http://geohash.org/dr5re

ตัวอย่างการใช้ js: http://github.com/davetroy/geohash-js


1

ในกรณีส่วนใหญ่คุณจะได้รับประโยชน์เพิ่มเติมจากการจัดเก็บข้อมูลเชิงสัมพันธ์มากกว่าที่คุณจะได้รับจากคีย์ / ค่าหรือการจัดเก็บคีย์ / ค่า / ประเภท มีความซับซ้อนมากรอบ ๆ การสืบค้นและการรายงานอย่างมีประสิทธิภาพเกี่ยวกับชุดรูปแบบข้อมูลนี้

คำแนะนำของฉันคือการประเมินอย่างใกล้ชิดว่าเครื่องชั่งของคุณต้องการ NoSQL จริงหรือไม่ก่อนที่จะพิจารณาวิธีการใช้


1
นี่คือตัวอย่างของปัญหาที่คุณอาจมี (และวิธีแก้ปัญหา) หากคุณต้องการคำนวณว่าจุดใดจุดหนึ่งอยู่ด้านในหรือด้านนอกของรูปทรงเรขาคณิต code.google.com/p/giscloud/wiki/SerializedSpatialIndexes
Jon Bringhurst

เฮ้ @ จอนนั่นจะเป็นการเพิ่มที่ดีขึ้นเป็นคำตอบ ด้วยวิธีนี้มันสามารถยืนได้ด้วยตัวของมันเองและคุณจะได้รับเครดิตถ้าคนอื่นคิดว่ามันมีบุญ!
JasonBirch


1

MongoDBมีสิ่งอำนวยความสะดวกในการสร้างและใช้ดัชนีทางธรณีวิทยาตามคุณสมบัติ 2d [x, y] ของ tuple ของเอกสารที่เข้มงวดและอนุญาตการสืบค้นชนิด 'ใกล้' และ 'ขอบเขต' อย่างไรก็ตามมันไม่ได้จัดการการแก้ไขใด ๆ สำหรับการฉายภาพและใช้แบบจำลองอุดมคติของพื้นราบ


0

ฉันจะใช้ที่เก็บคีย์ / ค่าเป็นเลเยอร์แคชเท่านั้นดูที่http://www.membase.org/หรือhttp://wiki.basho.com/display/RIAK/How+Things+Work (riak_kv_cache_backend)

คุณอาจยังต้องการให้ SQL เข้าถึงข้อมูลทั้งนี้ขึ้นอยู่กับความต้องการของแอปของคุณ


0
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.