我们将于8月11日在香港与kx的负责人进行交流，希望通过类似活动得到该公司的技术支持和对中国市场的关注。Windspeedo, kuhasu等有过kdb开发实践经验的朋友如有兴趣参加本次会面（本次会面将使用英文），请与我联系。
不是FD的人，是KX的高管。价格方面我们无所谓的，又不是自己掏腰包。主要是看你对KX技术的认真程度，应该是值得一见的。深圳这边的人我会安排邀请，主要是看其他地区的朋友。最后我想说KDB不是用来发烧的，想深入下去的朋友会了解进入这个圈子的必要性的。
承蒙tom大侠看得起，受宠若惊。 内存数据库这方面我没什么优化功能上的要求。过于细节的内存处理流程和底层算法通过直接交流就全了解也不太现实。。。这次我就不过去了。回来精神就麻烦几位大侠转达好了～不胜感激
We are already in close technical communications. Man, this IS real. The world of kdb is tough, arguably rewarding. If you are really SERIOUS with investing your time in it, join us.
谢谢tom，我知道这是个不错的更深入了解kdb的机会。 我想随着使用人数的增多，以及更多的kdb公开资料或技术支持，应该可以解决学习难度的问题。内存数据库是趋势和优势，就是看谁抢市场抢的快了，而这个又是先入为主占很大部分因素。
我们将于8月11日下午2点在深圳福田口岸会合，过关，3点30在中环文华东方酒店与kx,fd高管会面并做我们现有项目的展示。6-8点钟为鸡尾酒会，大陆过去的（不光是我们）与香港本地的kdb用户与kx自由交流。 请各位有kdb开发经验的（没动过手的爱好者不算），无论参会与否，请在本贴留言，提供你关心的kdb技术话题，我们将一并转达询问。我们从本次会面及以后与kx的交往中如果能获得一些资源或帮助，也可以和各位分享。
现在的感觉瓶颈不是在kdb+内部，而是各类接口和i/o的瓶颈上，这方面kdb+的支持不好，开发人员搞起来不是很容易，尤其在效率优化方面。 另外问下，kdb+处理底层数据的流程是怎样的呢？这个一直没搞明白 另外一个想法，计算机语言没有版权，所以介绍C的书才一大堆一大堆的，q和kdb+在这方面有没有什么绿色通道，既可以方便普及，又可以不用担心法律问题? 谢谢
1.通常编接口的语言是C#，C++，java，asm，易语言，.net,对吧，而对于不同语言，数据传输是会有瓶颈和效率问题的吧。尽管q在kdb+环境运行和处理数据很快，但交互的话效率会下降，再加上接口程序本身的效率问题。而如果kdb+能在这方面多提供支持，相信效率应该可以还有提高的吧。 2.就是kdb+和q处理数据的过程啊，包括读取数据，导入，内存的寻址和流程啊，了解了这个，虽然晦涩难懂点儿，才能有针对性的编写高效率执行代码啊。就好象一般行数据处理擅长数据库的代码，如果放在列数据库中执行的话，效率可能会大打折扣的道理一样。 只是一点想法而已，也不能要求某个商业软件做到完美不是，而且他们也没提供什么好处...
11日下午会晤了KX的CEO和FD的亚太DIRECTOR，以及Chris Burke。展示了我们对KDB+的认识和开发中项目，也询问了一些技术问题。晚间COCKTAIL，结识了香港地区的部分KDB用户。总结下来： 1）亚洲包括中国是其近期开始关注的地区； 2）KX自身人力不足，即使是文档支持这样的工作都难以令人满意，FD的商业服务可能是其最主要的技术传递模式； 3）FD会在大陆举行培训班； 4）缺乏DEBUGGER、PROFILER、TIMER等重要工具； 5）Q的数据存储按列来做，在内存上连续分配，这是其速度快的基本原因。程序内核小是另一个。 6）跟ITFIN讨论的意见是Q的接口都是基于SOCKET，不应有很大的瓶颈，或许是接口本身的实现效率不够高。 7）KDB如果编码不当的话完全体现不出其性能优势，只有通过具体实例分析（请教CHRIS这样的人）才能给出答案。