TDH_Socket与HandlerSocket和MySQL的特性优缺点对比

TDH_SOCKET

HandlerSocket

SQL

Dynamic IOStrategy

Same-thread IOStrategy

one-thread-per-connection

• 1. 无需SQL解析
  2. 可在THD上cache open过的table(可配置关闭)
  3. 一次轮询只lock一次table
  4. 请求按table的hash值平均分配到可活动的线程上
  5. 如果有table被过多访问,那么此table的请求可被分配到多个线程上
  6. 在带io请求少时,可以用较少的线程work.来减少锁征用导致的上下文切换
  7. 有一定量带io请求时,能调整worker线程数来充分利用io资源.
  8. 当带io请求巨多时,将区分带io的请求和不带io的请求.分别用两个线程池来执行,防止带io的请求堵住不带io的请求.
  9. 还可以设置流控带io的请求数来防止client的堵塞情况,能使DB继续输出较高的QPS
  10. 如果返回大批量数据可以以stream的方式返回,避免过多占用内存

• 1. 无需SQL解析
  2. 可在THD上cache open过的table(不可配置关闭)
  3. 一次轮询只lock一次table
  4. worker线程数固定,且无法做请求数的平衡,只能做连接数的平衡

• 1. 可global的做table的cache
  2. 每次请求都lock一次table

• 1. 一次轮询的请求一次commit
  2. 请求按table的hash值平均分配到写线程上,即同一个表肯定在一个写线程的被执行,不会有死锁的问题,也不会有同一条row的锁问题.
  3. 支持Batch方式的小事务,Batch内的请求保证同时成功,同时失败
  4. 可以在Client端通过指定hash的方式,来控制请求被指定的线程执行,来避免一些锁或死锁

• 1. 一次轮询的请求一次commit
  2. 可配置多个写线程,但是有一个user_lock保证只有一个写线程在工作,来防止死锁

• 1. 一次请求一次commit

多表insert会有自增id获取失败的问题(bug)

• 1. DDL操作不会被hang住(因为可以主动close 被cache的table)
  1. 支持KILL 命令直接终止正在执行的操作
  1. 大部分参数都为在线可配置
  1. status数据监控完善

• 1. DDL会被hang住,因为handlersocket只open table不管主动close table,只有在流量较小time out时才会close table

1. client端不需要openIndex,直接请求即可(如:

client.query().use(“test”).select(“id”, “a”, “b”, “c”).from(“t”)

.where().fields(“a”).in(["1", "1"], ["2"], ["1"]).get())

1. server端只需要一个port 就能做读写分离
2. 可支持一些MySQL的内置函数
   1. 现在支持Update/Insert的时候可以插入now()

1. 基于辅助索引的联合主键可以支持简单的order by
   1. 只能支持=的order by

5.  Java客户端支持JDBC

• 1. 读写分离需要在server端配置两个port是实现
  2. client请求前需要先openIndex