在键值数据库中使用二级索引

偷偷努力，悄无声息地变强，然后惊艳所有人！哈哈，小伙伴们又来学习啦~今天我将给大家介绍《在键值数据库中使用二级索引》，这篇文章主要会讲到等等知识点，不知道大家对其都有多少了解，下面我们就一起来看一吧！当然，非常希望大家能多多评论，给出合理的建议，我们一起学习，一起进步！

可以说，我有这样的数据结构

type user struct {
      uuid string 
      username string
      email string 
      password string 
      firstname string 
      lastname string
}

我将用户 []user 存储到 leveldb 中的键/值数据库中。唯一的密钥将是 uuid，然后用户结构将根据此 uuid 进行编码和存储。

var network bytes.Buffer // Stand-in for a network connection
enc := gob.NewEncoder(&network)
err := enc.Encode(user)
   if err != nil {
      log.Println("Error in encoding gob")
      return "", err
 }
err = dbSession.DBSession.Put([]byte(user.UserID), network.Bytes(), nil)

由于所有条目的关键是唯一的 uuid，因此我想在电子邮件上创建二级索引，这样我就不必扫描数据库中存在的所有条目来查找与电子邮件相对应的特定条目。

我做了什么： 我创建了一个名为 sindex 的键，并在其中存储了一个 map[string][string] 数据结构，其中键是电子邮件，值是 uuid。每次有新条目进入时，此 sindex 都会更新以适应新的 uuid 和电子邮件。

这是一个糟糕的方法： 因为随着数据的增长，需要获取sindex对应的整个map并进行解码，如果email不存在，则向sindex添加一个新的key，对其进行编码并再次存储回来。

b 树更适合。

我的问题：将二级索引数据存储在数据库本身是否正确，如果不是，我应该使用什么策略来实现二级索引，我知道二级索引的选择受数据影响很大，但是有什么好的办法除了 b-tree、hashmap 之外还有哪些框索引算法？

解决方案

将二级索引数据存储在数据库本身是否正确

是的，这没问题。但正如 Jonas 在评论中指出的那样，您应该将电子邮件作为键，将 UUID 作为值。另一种选择是使用电子邮件作为数据库的密钥，而不是使用 UUID。这样您就不需要使用二级索引。

另一种获得更好性能的策略，您可以使用内存数据库，例如Redis（或者LevelDB本身可以用于将数据存储在内存中）来存储二级索引（电子邮件作为键，UUID作为值）。

除了 B-Tree、HashMap 之外，还有什么好的开箱即用索引算法

不管怎样，B-Tree和HashMap是数据结构，而不是算法。实际上，您所做的并不是使用 HashMap 进行索引，它只是将 HashMap 存储为键的值。索引通常取决于 DBMS 的实现（我们只能从它们提供的选项中进行选择）。

所以，关于用于索引的数据结构，它的好坏，实际上取决于用例。例如，如果您需要进行范围搜索，您可以使用 B-Tree（大多数 DBMS 默认使用）、B+ 树（MySQL InnoDB 默认使用）和 Skip List（Redis 使用此数据结构进行排序）放）。您可以阅读有关 Redis Sorted Set 二级索引的更多信息 here。

对于您的情况，您只需将电子邮件存储为键，将 UUID 作为值存储。哈希表通常用于此目的。大多数 DBMS 使用这种数据结构进行主键访问，时间复杂度仅为 O(1)。而且我相信LevelDB的实现也是基于这个数据结构的。

本篇关于《在键值数据库中使用二级索引》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于Golang的相关知识，请关注golang学习网公众号！