我有一个HBase架构设计相关的问题.问题很简单 - 我在hbase中存储"通知",每个都有一个状态("new","see"和"read").以下是我需要提供的API:
我有一些想法,我想看看其中一个是否最好,或者我是否完全错过了一个好的策略.这三种情况相同,我认为每个通知都有一行,并且在rowkey中有用户ID是要走的路.为了按时间顺序排列分页,我需要在那里有一个反向时间戳.我想将所有notifs保存在一个表中(因此我不必为"为用户调用所有notificatiosn"调用合并排序)并且不想为二级索引表编写批处理作业(因为更新到计数和状态应该是实时的).
最简单的方法是(1)行键是"userId_reverseTimestamp"并对客户端的状态进行过滤.这似乎很幼稚,因为我们将通过网络发送大量不必要的数据.
下一种可能性是(2)将状态编码到rowkey中,因此要么"userId_reverseTimestamp_status",要么对扫描进行rowkey正则表达式过滤.我看到的第一个问题是需要删除行并在状态更改时将通知数据复制到新行(可能每个通知应该发生两次).此外,由于状态是rowkey的最后一部分,因此对于每个用户,我们将扫描许多额外的行.这是一个重大的表现吗？最后,为了更改状态,我需要知道以前的状态是什么(构建行键),否则我将需要进行另一次扫描.
我的最后一个想法是(3)有两个列族,一个用于静态notif数据,一个用作状态的标志,即"s:read"或"s:new",带有's'作为cf以及作为限定符的状态.每行只有一个,我可以针对该cf执行MultipleColumnPrefixFilter或SkipFilter w/ColumnPrefixFilter.在这里,我将不得不删除并创建状态更改列,但它应该比复制整行更轻量级.我唯一担心的是HBase书中警告说HBase不能很好地处理"超过2或3列系列" - 也许如果系统需要扩展具有更多的查询功能,那么多cf策略将无法扩展.
所以(1)似乎会有太多的网络开销.(2)似乎浪费了复制数据所花费的成本,(3)可能会导致太多家庭出现问题.在(2)和(3)之间,哪种类型的滤波器应该提供更好的性能？在这两种情况下,扫描都会查看用户的每一行,这可能主要是读取通知 - 这会有更好的性能.我想我倾向于(3) - 还有其他选择(或调整)我错过了吗？
再次模式匹配列表时,可以使用Nil检查空列表.但是,如果基础类型是Iterable,您仍然可以检查Nil,它将为空集等中断...请参阅以下REPL会话:
scala> val l: Iterable[Int] = List()
l: Iterable[Int] = List()
scala> l match {
| case Nil => 1
| case _ => 2
| }
res0: Int = 1
scala> val l: Iterable[Int] = Set()
l: Iterable[Int] = Set()
scala> l match {
| case Nil => 1
| case _ => 2
| }
res2: Int = 2
问题是 - 我该如何防止这类问题？显然,如果l是类型List,那就不是bug.如果l的类型为Set,则不会编译.但是,如果我们有一个具有列表的类,定义一个模式以这种方式匹配的函数,然后有人改变该类以采用通用迭代呢？这种Nil vs. _模式总体上是一个坏主意吗？
如果这是重复的道歉 - 我做了一些搜索,并没有找到我需要的东西.
我们的应用程序具有性能关键部分,可将Play 2.0 Enumerator(可被视为a Stream)转换为List(或类似).我们将使用该fold方法,Enumerator问题是最有效的方法.(我将使用Stream而不是Enumerator代码,但想法应该是相同的.)
val incoming: Stream[Int] = ???
val result: Seq[Int] = incoming.fold(Seq.empty)(_ + _)
val result2: Seq[Int] = incoming.fold(MutableList.empty(_ += _).toSeq
所以问题基本上是,如何重复附加到一个不可变的Vector比较,反复附加到一个可变的MutableList或ListBuffer性能关键代码？我们之所以被抛弃只是List因为我们需要O(1)追加(而不是前置).但是,可变数据结构是否在性能或垃圾收集方面为我们带来了任何东西？
有趣的是,在启用这些选项后,我们的构建似乎更慢.我在网上搜索了一下,试图做一些比较,但没有找到结论.想知道是否有人知道.