YunTable 1.0beta 内部测试

[吴朱华]

各位：

上周已经将最新的YunTable资料和大家共享了，明天估计会正式对外发布YunTable 1.0beta，而今天准备提前开放给群里面，让各位来抢先试用一下，因为虽然现在YunTable的性能已经在多个场景得到验证，但在使用方面还有很大的改进余地， 下面是具体的资料：

产品简介：http://peopleyun.com/?page_id=1194

执行文件下载：http://peopleyun.com/?page_id=1201

上手教程：http://peopleyun.com/?page_id=1205

如果各位碰到问题，请保持稳定，因为现在还处于Beta阶段，如果出现问题也是正常的，同时请看一下YunTable的上手教程的第17个段落来准备一下相关的资料，并发给我^_^

还有，很多同学提到了开源这个问题，我们这边情况是这样的，因为在最近一年，YunTable已经经过多轮迭代和测试，所以在核心技术方面积累很多，为了保护这些核心技术，我们这边准备先对这些基于代码的核心技术申请专利，等完成专利之后，会正式考虑开源这个问题。

--
Cheers！
人云科技 PeopleYun.com
只有掌握和控制最核心的云计算技术，才能在这场巨大的浪潮中处于主导！！！

[吴朱华]

收到，你这个问题，我们今天会fix和更新的，还有从最近几天，每天会发布新的文档，请各位关注^_^

另外建议可执行文件的名称全部小写，且包含 yuntable 这个关键词，更符合常用软件的传统 :P ？

这个建议我们收到，不错，让我们团队等一下讨论一下^_^

在 2012年5月29日 上午12:33，Dean Lee <xsli...@gmail.com>写道：

startMaster 和 startRegion 不论是否 sudo 运行都会冒出这样一行提示：
ioctl: Cannot assign requested address
（但结果和使用却完全正常 只是这条消息看着不爽）
是不是哪个分支没判断就尝试分配了?

（不是致命问题 就不发到邮件列表了 :D）

$ uname --all
Linux dean-laptop 3.2.0-24-generic #39-Ubuntu SMP Mon May 21 16:52:17
UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

$ ./startMaster
The Current Log File Path is master.log.
[3708] 29 May 00:14:38 - The YunTable Version is 1.0beta.
[3708] 29 May 00:14:38 - The Current Process id: 3708.
[3708] 29 May 00:14:38 - Loading the master info from conf path is
conf/master.conf.
ioctl: Cannot assign requested address
[3708] 29 May 00:14:38 * Ignoring Processing the Local Conf File, The
Master Node will use the default setting.
[3708] 29 May 00:14:38 - The daemon for master side flushing has started.
[3708] 29 May 00:14:38 - The Master Server is starting at
127.0.0.1:8301 and will handle request.

另外建议可执行文件的名称全部小写，且包含 yuntable 这个关键词，更符合常用软件的传统 :P

Best wishes,
Dean (@xslidian)


2012/5/28 吴朱华 <ike...@gmail.com>:

[吴朱华]

Dean:

你那个问题已经fix了，你可以重新下载一下试试http://peopleyun.com/?page_id=1201。

[Dean Lee]

收到~ 测试正常~

居然没有 delete_table 吖 还得手动到两个 conf 里面删除

Best wishes,
Dean (@xslidian)

2012/5/29 吴朱华 <ike...@gmail.com>:

> Dean:
>
> 你那个问题已经fix了，你可以重新下载一下试试http://peopleyun.com/?page_id=1201。
>
>
> 在 2012年5月29日 上午11:35，吴朱华 <ike...@gmail.com>写道：
>>
>>
>> 收到，你这个问题，我们今天会fix和更新的，还有从最近几天，每天会发布新的文档，请各位关注^_^
>>
>> 另外建议可执行文件的名称全部小写，且包含 yuntable 这个关键词，更符合常用软件的传统 :P ？
>> 这个建议我们收到，不错，让我们团队等一下讨论一下^_^
>>
>>
>> 在 2012年5月29日 上午12:33，Dean Lee <xsli...@gmail.com>写道：
>>
>>> startMaster 和 startRegion 不论是否 sudo 运行都会冒出这样一行提示：
>>> ioctl: Cannot assign requested address
>>> （但结果和使用却完全正常 只是这条消息看着不爽）
>>> 是不是哪个分支没判断就尝试分配了?
>>>

>>> [恕删]

[longxi...@gmail.com]

HI,吴工，你好。

我问一下，YunTable有没有跟InfoBright（IEE）,Sybase, Orace Exadata比较详细的对比测试呢？如果有的更具体的指标的话，可能会更有说服力。

[吴朱华]

谢谢Dean Lee和罗工的意见。

首先，delete_table这个Feature已经实现了，马上就会添加到YunClient中；

其次，关于几个产品的对比测试，其中InfoBright已经有对比数据，而且性能优势非常明显，这个将会在本周发出来。对于Oracle Exadata，我们这边在寻找合作伙伴来提供类似的环境，如果不行的话，GreenPlum是没有问题的，我们会和合作伙伴一起选择1-2个场景来进行benchmark。

[longxi...@gmail.com]

感谢吴哥对我回答。

目前我们的产品用的是InfoBright，如果YunTable可以话的，以后也想往YunTable转，当然，相信你们也一定行的，我对你们YunTable关注一年多了，算是比较资深了，呵呵。

我再提两点：

1，YunTable对数据是否有压缩，压缩比有多少。据我们测试InfoBright，它的压缩比比较高，达到20：1了，但就会引入另一个问题，查询性能相对差一点，需要解压。

2，是否有提供分布式导入数据的工具呢？

希望对你们的产品有帮助，谢谢。

[吴朱华]

罗同学：

这两天很忙，不好意思，回复慢了一点，但我已经加你GTalk了，保持交流，下面是我对你问题的答复，请你看一下，并提一下意见：

1. YunTable的三大核心技术中，压缩有支持，压缩比的大小和数据本身非常相关，由于我们采用压缩的算法和infobright差别不会特别大，所以对于同类数据，在压缩比应该是伯仲之间；

2. 分布式导入数据的工具，我们1.0beta有相关的导入工具，支持分布式导入，有可能和你理解的偏差，但这块我们之间能沟通，尽可能地方便用户总是应该做的事情。

[吴朱华]

大家好：

呵呵，YunTable 1.0beta新的Release已经上传了，包括Drop Table和日志打印控制等特性，并整合一下现有YunTable的使用教程；

下面是具体的链接：

下载YunTable

使用YunTable

大家可以看一下，还有1.0beta的32位版本，明天会发布，敬请期待^_^

[Colin Shi]

把去年的0.9版本试了一下，在ubuntu 12.04下报错

undefined reference to pthread_create

应该是Makefile的问题，改一下就过了，但是没有人注意到么？

还是在其他linux版本下木有问题？

[longxi...@gmail.com]

找不到pthread库了，编译的时候加上就可以了。

[Colin Shi]

CC = gcc -g -Wall

CFLAGS = -I include/ -lpthread

UTIL_SRC = util/*.c

REGION_SRC = region/*.c

region:

$(CC) $(CFLAGS) ${UTIL_SRC} ${REGION_SRC} -o startRegion

我改动了一下-lpthread的位置，编译也通过了；其实我没看出来这儿有啥

问题，但是ubuntu里不行，有大侠能解释一下么？

[redchen]

请问Colin Shi是使用64位系统吗？

（64位）把-lpthread 改为 -pthread

-pthread是兼容-lpthread的，-pthread支持32位和64位，新的gcc是采用-pthread加载线程库的

[吴朱华]

Colin，你先试一下0.9，我这边这周会发一个1.0版本给社区，希望大家到时多提反馈意见^_^

[张万凯]

用gcc编译程序时，确实应该把链接库放在最后。

如果-lpthread后面的目标文件用到了pthread库的话，编译会通不过。

在 2012年7月25日 上午11:20，Colin Shi <shi...@gmail.com>写道：

[er robit]

开发速度也快了点，。。。

我怀疑是实现了个infobright 的分布式剥离mysql 版本。。。

具体等看代码。

2012/6/5 吴朱华 <ike...@gmail.com>

[吴朱华]

呵呵，的确可以这样理解，但如果理解成SAP Hana那可能更精确^_^