[武術]140626 吳式太極拳 札記 五個基本動作

一動必有一用

老師今天提到五個基本反覆練熟的基本動作，

攬雀尾 單鞭 摟膝拗步 雲手 倒輦猴
熟練之後妙用無窮。

光是起式，不與人鬥力，一鬆一緊就可以讓人失去重心。

這次上課，老師讓大家都試試看那是怎樣的感覺。
老師的聽勁，非常的敏銳。當他發勁時，不忘觀察他的後背動作。

[elasticsearch]date_detection false

動態的mapping


動態的新增欄位與 type ，在elasticsearch 是個非常直覺的行為。
上文有先說明過，關於在 elasticsearch put 欄位的資料時，這個欄位的mapping 會依據他第一次 index 資料時欄位的 type 來當預設值。

所以，預設的 dynamic mapping 是開啟的。但是可能會發生，我們非預期的情況。date 資訊就是常見的一種，有時我們欄位的值，並不是 date 欄位，但是 elasticsearch會幫我們判定成 date。

舉個例子來說， 在索引時note欄位第一次出現的值，被判定為 date。
{"note":"2014-06-25"}

再來的資料是，

{"note":"this is note"}

會發生 note的 type已經被定為 date ，但是，但是你要index 的 value 的情況。(會出現 malformed date)

此時，就可以關掉預設 "date_detection" ，讓 elasticsearch 不會自動幫我們把 string 裡面的值判定成 date type。
(原始的 type 可參照之前文章)

PUT /my_index{
    "mappings": {
        "my_type": {
            "date_detection": false
        }
    }
}

cf.


peicheng-note: elasticsearch 相關 elasticsearch文章
http://peichengnote.blogspot.tw/search/label/elasticsearch

peicheng note: [elasticsearch] 再談 _all field

http://peichengnote.blogspot.tw/2014/06/elasticsearch-all-field.html

peicheng note: [elasticsearch]range query depends on the field type

http://peichengnote.blogspot.tw/2014/06/elasticsearchrange-query-depends-on.html

peicheng-note: [elasticsearch] document id _id field uuid
http://peichengnote.blogspot.tw/2014/05/elasticsearch-document-id-id-field-uuid.html
peicheng-note: [elasticsearch/logstash] logstash id 自動產生 document id "_id" automatic id generation
http://peichengnote.blogspot.tw/2014/04/elasticsearchlogstash-logstash-id.html
Customising dynamic mapping
http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/custom-dynamic-mapping.html
Root Object Type
http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/mapping-root-object-type.html

[elasticsearch] 再談 _all field

當我們索引一份文件的時候，所有的filed


當我們索引一份文件時，會所有的filed 的 text 拆成 (analyze) 成 terms ，並且使用 terms 與 document id 建成 inverted index 。

所以當我們做 full text search時，對 query string ，使用同樣的analyze 流程，去確保拆出同樣的 term 去對index search。

所以，對於 全文搜索來說，我們必須搞清楚 每個 field 是怎麼被定義的，才能確保搜尋出來的結果是正確的。

舉個例來說，
有個 data field 他有一個 exact value 只有單一個 term "2014-09-15"
_all field 包含著全部的 full text field, 所以夠過 analysis 的流程會把 data 轉成三個  terms "2014","09","15"

如果，對 _all field 做search ,query string 是 2014 時，會返回 12 的 tweets match。

GET /_search?q=2014

當我們 query "2014-09-15" 時，query string會被拆成 "2014","09","15" 三個 terms 並且 match 任何包含這三個term的 result。

GET /_search?q=2014-09-15

但是，如果使用 "2014-09-15" 對 date field 做search
他會對 date 做 exact search，只會 match 到 1的 result。

GET /_search?q=date:2014-09-15

當我們使用 2014 這個query string時，

GET /_search?q=date:2014 # 0 result

以上的例子來說明 default 的 _all field 與對欄位做search的差異。


ccf. when analyzers are used

[elasticsearch]range query depends on the field type

在elasticsearch 使用 range query時，是根據 field type 也就是欄位的類別來決定對此欄位做怎樣的操作。

若是 string type 就是用 TermRangeQuery
若是 number / data 就使用 NumericRangeQuery


舉個例子來看，

• 建立 index 

PUT /my_index/

• put type mapping 

logs 這個type有兩個 field，一個是name把type定成 string。另一個是nid 設定成 integer type。

PUT /my_index/logs/_mapping
{
   "properties": {
      "name": {
         "type": "string"
      },
      "nid": {
         "type": "integer"
      }
   }
}

• 分別 index 兩筆 records

POST /my_index/logs

{

    "name":"pc","nid":100

    

}

POST /my_index/logs

{

    "name":"pc2","nid":"100"

    

}

第一筆，type 都與 mapping相同

第二筆，type 與 mapping 有相同不同，但是在索引時，他會盡量幫我們做一個casting檢查，但是並不會改變 _source的內容。也就是說，elasticsearch 在拿 document  每個欄位出來 index 值時，他會根據 mapping 去做parse 。

GET /my_index/logs/_search

{

   "query": {

      "match_all": {}

   }

}

respose:

{

   "took": 18,

   "timed_out": false,

   "_shards": {

      "total": 5,

      "successful": 5,

      "failed": 0

   },

   "hits": {

      "total": 2,

      "max_score": 1,

      "hits": [

         {

            "_index": "my_index",

            "_type": "logs",

            "_id": "-ph1-zIoR-eYuuxnctYL_w",

            "_score": 1,

            "_source": {

               "name": "pc2",

               "nid": "100"

            }

         },

         {

            "_index": "my_index",

            "_type": "logs",

            "_id": "x4mLJi0vR_iiR9v2l7BiAg",

            "_score": 1,

            "_source": {

               "name": "pc",

               "nid": 100

            }

         }

      ]

   }

}

• 如果是 index 時的 欄位 type 與 mapping 不同時

POST /my_index/logs

{

    "name":"pc2","nid":"abc"

    

}

response:

{

   "error": "MapperParsingException[failed to parse [nid]]; nested: NumberFormatException[For input string: \"abc\"]; ",

   "status": 400

}

• 因為不能 cast 丟出 Exception

org.elasticsearch.index.mapper.MapperParsingException: failed to parse [nid]

at org.elasticsearch.index.mapper.core.AbstractFieldMapper.parse(AbstractFieldMapper.java:418)

at org.elasticsearch.index.mapper.object.ObjectMapper.serializeValue(ObjectMapper.java:637)

at org.elasticsearch.index.mapper.object.ObjectMapper.parse(ObjectMapper.java:490)

at org.elasticsearch.index.mapper.DocumentMapper.parse(DocumentMapper.java:515)

at org.elasticsearch.index.mapper.DocumentMapper.parse(DocumentMapper.java:462)

at org.elasticsearch.index.shard.service.InternalIndexShard.prepareCreate(InternalIndexShard.java:373)

at org.elasticsearch.action.index.TransportIndexAction.shardOperationOnPrimary(TransportIndexAction.java:203)

at org.elasticsearch.action.support.replication.TransportShardReplicationOperationAction$AsyncShardOperationAction.performOnPrimary(TransportShardReplicationOperationAction.java:534)

at org.elasticsearch.action.support.replication.TransportShardReplicationOperationAction$AsyncShardOperationAction$1.run(TransportShardReplicationOperationAction.java:433)

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)

at java.lang.Thread.run(Thread.java:745)

Caused by: java.lang.NumberFormatException: For input string: "abc"

at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)

at java.lang.Integer.parseInt(Integer.java:492)

at java.lang.Integer.parseInt(Integer.java:527)

at org.elasticsearch.common.xcontent.support.AbstractXContentParser.intValue(AbstractXContentParser.java:126)

at org.elasticsearch.index.mapper.core.IntegerFieldMapper.innerParseCreateField(IntegerFieldMapper.java:307)

at org.elasticsearch.index.mapper.core.NumberFieldMapper.parseCreateField(NumberFieldMapper.java:224)

at org.elasticsearch.index.mapper.core.AbstractFieldMapper.parse(AbstractFieldMapper.java:408)

... 11 more

ref:
Matches documents with fields that have terms within a certain range. The type of the Lucene query depends on the field type, for string fields, the TermRangeQuery, while for number/date fields, the query is a NumericRangeQuery.

Range Query
http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/query-dsl-range-query.html

[武術]吳式太極拳 札記 關於 香港 鄭榮光 與 鄭天熊

週日 抽了一天到霍老師的拳館去，其實非常喜歡聽老師講歷史故事。

• 吳鑑泉的單鞭馬步低 功力高，每個式子的狀態都表持可以自由移動起手起腳的狀態。
• 打拳時，要放鬆
• 由著熟，熟練之後懂勁，每一招每式都在套路裡面，所以可以致用。在打套路時，每一個點都可以想說，對手是怎麼進擊，要用怎樣的方式去反應。
• 高手拿人，一動手就已經控制到手臂的關節了。
• 與老師接手，那個力道，如柔中藏剛，手一撥開時那力道之巧妙如 成年人般。
• 鄭天熊的 24 式 是把式子名稱改的生活化比較財富一點，像是 第一式 運氣藏精 他叫做抱金盆。鄭榮光的健身院在香港開的很多，很蓬勃發展。
• 那時候老師，常常在很多師兄那邊當助教，他很用心的去問像 公儀老師，還是大揆 大齊 大新他們 有缺助教嗎？如果不嫌棄，他就過去那邊幫忙教學。所以，當時，吳光宇與他相差15歲，早年教的拳都是老師教他的。
• 當時，鄭天熊與他叔父鄭榮光也會跑去跟大揆私人學習。

[python][requests] https Python Requests throwing up SSLError

越來越多網站支援 https ，甚至直接幫你導到 https去。
在本來使用 http 的網址在做 requests 操作時，可直接使用 verify to False 略過使用SSL certificate。

Requests can also ignore verifying the SSL certificate if you set verify to False.

>>> requests.get('https://kennethreitz.com', verify=False)
<Response [200]>

Advanced Usage — Requests 2.3.0 documentation
http://docs.python-requests.org/en/latest/user/advanced/#ssl-cert-verification

[elasticsearch] Elasticsearch high load/CPU usage CPU 用量

在使用 elasticsearch的時候有時會發現一些 cpu 用量飆高的情況 除了看 log外 ，

• 查看 hot threads
  http://localhost:9200/_nodes/hot_threads
• 查看 jvm 相關訊息
  http://localhost:9200/_nodes/stats?jvm

[elasticsearch] 從 deep paging 談起 scan & scroll : an effective way out put data 高效能輸出

• search_type 草略介紹
• why use scan & scroll
• deep paging problems / 所以可能只提供前幾筆 估計值

 elasticsearch 內 有對不同的 search 情境 提供多種的 search type  ，像是只想取得 document 個數的 search_type=count ，還有提供高效輸出結果的 scan 。

curl -XGET 'localhost:9200/_search?search_type=scan&scroll=10m&size=50' -d '
{
    "query" : {
        "match_all" : {}
    }
}
'

scan 與 scroll

scan這個 search type 與 scroll api 就是為了從 elasticsearch 高效的獲取比較大量的 document。 使用 scan就可以避免調 deep paging 的問題。

deep paging 

deep paging 是個非常容易定義出來的問題。當search engine要 return search result的時候， kernel 必須準備對應的 in -memory 的資料結構回應。簡單來說，如果我們想要回應 

10000個分頁，每個分頁有20的result，那們就必須要有一個 20*10000=200 000 個 單位的結構。

使用 scan 剛好可以解決 deep paging遇到的問題。在 elasticsearch中 ，如果我們有 5個 primary shards，我們想返回 top 10 的內容，每個shard都會返回 top 10 到 requesting node上做彙整，最後再挑出 top 10。

取個例子來看，要是我們要取的分頁是1000 每頁有十筆，當我們要往後取時，就要在每個shard取出相對應的top n 並且skip 掉非常大量的數目。

有此看來就知道，在分散式的搜尋引擎中 sorting 這種資訊的成本非常高。這也就是為什麼，一般的web都不會回超過 一定量的分頁數。

分頁估計值

在顯示大量資料會出現幾個分頁，甚至是有幾筆。最常使用的技巧，就是估計值。

你可以估計出，這個 term 在一定量的 資料 出現比例是多少。在大資料的前提下，你就可以推估出，這個 term在全部的資料有出現大約多少筆。

使用 scan 要回一個 scroll_id

curl -XGET 'localhost:9200/_search?search_type=scan&scroll=10m&size=50' -d '
{
    "query" : {
        "match_all" : {}
    },
    "size":1000}
'

10m 表示 scroll 開啟的時間是 10分鐘 ,30s 是 30秒

在這裡還可以指定每次返回的size是多大。

執行後會返回一個 scroll id 在使用 scroll  api 去把資料取回來。

scroll 是一個  base64 encode 的 字串。

這裡的 size 會被執行到每個 shard上去，所以實際返回的數目應該會是

size * number_of_primary_shards

使用 scroll api 可以把 document 取回，這裡取回的 document 省去了sorting的開銷。

curl -XGET 'localhost:9200/_search/scroll?scroll=10m' -d 'c2NhbjsxOjBLMzdpWEtqU2IyZHlmVURPeFJOZnc7MzowSzM3aVhLalNiMmR5ZlVET3hSTmZ3OzU6MEszN2lYS2pTYjJkeWZVRE94Uk5mdzsyOjBLMzdpWEtqU2IyZHlmVURPeFJOZnc7NDowSzM3aVhLalNiMmR5ZlVET3hSTmZ3Ow=='

"The deep paging problem is quite easy to define. To return search results Solr must prepare an in-memory structure and return part of it. Returning the part of the structure is simple, if that part comes from the beginning of the structure. However, if we want to return page number 10.000 (where we return 20 results per page) Solr needs to prepare a structure containing minimum of 200.000 elements (10.000 * 20). You see that it not only takes time, but also memory."

ref.

Solr 4.7 – Efficient Deep Paging | Javalobby

http://java.dzone.com/articles/solr-47-efficient-deep

Scan and scroll http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/scan-scroll.html

Search Type

http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/search-request-search-type.html

Pagination

http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/pagination.html

peicheng-note: elasticsearch 相關 elasticsearch文章
http://peichengnote.blogspot.tw/search/label/elasticsearch
peicheng-note: [elasticsearch] document id _id field uuid
http://peichengnote.blogspot.tw/2014/05/elasticsearch-document-id-id-field-uuid.html
peicheng-note: [elasticsearch/logstash] logstash id 自動產生 document id "_id" automatic id generation
http://peichengnote.blogspot.tw/2014/04/elasticsearchlogstash-logstash-id.html

[武術]吳式太極拳班 武術的精神

今天老師分享了幾個觀念

• 武術最主要的精神就是用，再來才有身體的養。
• 套路裡面的每一動都有他的奧妙所在，很多東西都藏在套路裡面了。
• 像是一個攬雀尾練熟懂勁就夠了。ex 楊露禪
• 節節放鬆 

[elasticsearch]elasticsearch-hadoop using mapreduce with elasticsearch 之二 情境

之前已經寫過一篇關於在 Hadoop 下 使用 Elasticsearch 的 elasticsearch-hadoop lib 的說明。

這裡在重述幾件事情，
Hadoop MapReduce Job 通常下列的典型流程。


1. Job config : input, output, input format, output format , etc
2. Mapper 處理每個 從 HDFS 讀入的 line 並且 輸出 key value pair  到 Reducer。 

3. In reducer 會匯集所有相同key 值的 value 並得到最終結果並寫回HDFS。
elasticsearch-hadoop lib 就是在從事這樣的操作。

有幾個常見的 scenarios。

1. 從 Elasticsearch 讀取(query)資料
- 使用Mapreduce job來處理資料
- 把 output結果存到 HDFS (或是再次把output 存入ElasticSearch / ESindexing operation)

2. 使用 MapReduce 對原先存放在 HDFS的資料做操作。
- 處理資料
- 把結果輸出到 Elasticsearch (即是 Elasticsearch 的 索引過程)

More Link
peicheng note: [elasticsearch]elasticsearch-hadoop using mapreduce with elasticsearch
http://peichengnote.blogspot.tw/2014/06/elasticsearchelasticsearch-hadoop-using.html
peicheng note: elasticsearch 相關 elasticsearch文章
http://peichengnote.blogspot.tw/search/label/elasticsearch

[elasticsearch]Users with Elasticsearch 1.2.0 should immediately upgrade to 1.2.1

Due to the routing problmes ,Elasticsearch official blog recommend that anyone using version 1.2.0 upgrade immediately to this 1.2.1 release.

“We removed the 1.2.0 release from our download site and repositories due to the severity of the bug. Users with Elasticsearch 1.2.0 should immediately upgrade to 1.2.1.”

1.2.0 版已經從官方的 download 下架了，從這篇文章，可以清楚了解 Elasticsearch的原理。當一個 document要建立索引時，會產生一個 document id，那個id 透過 hash 的方式會 routing 到特定的 shard 上。


"Before we can discuss the tool we developed to help fix damage from the bug, we have to understand the problem the bug created. When Elasticsearch stores a document it has to decide which shard to put the document in. It does this by computing a hash of the document’s “UID”, which is by default the type#id tuple of the document. Elasticsearch then uses that hash modulo the number of shards to pick a shard. We have to make sure that this hash function works the same across different versions of Elasticsearch. If it doesn’t, version X could expect to find a given document in shard 1 and version X+1 could expect the same document in shard 2. In this case, version X+1 could not directly get the document if it were indexed while running version X."

這裡的一個routing 問題就在於 1.2.0 的 hash  方式導致 consistent hash 跟以往不同了。還有可能會導致，你使用 ID 找不到索引的 docuemnt。

The bug in 1.2.0 broke this consistent, cross-version hashing. 1.2.1 restored the same hash operation as used in previous versions (except 1.2.0). Once you’ve upgraded to 1.2.1 there are a few potential problems:

• documents indexed in 1.2.0 are now in the “wrong” shard. You may not be able to retrieve (get) documents by ID when they were indexed in the wrong shard.
• documents that were updated in 1.2.0 may now exist in two places: the correct shard (as in 1.2.1) and the wrong shard (as in 1.2.0).

Elasticsearch.org Elasticsearch 1.2.1 Released | Blog | Elasticsearch

http://www.elasticsearch.org/blog/elasticsearch-1-2-1-released/

Elasticsearch.org A Tool To Help With Routing Issues From Elasticsearch 1.2.0 | Blog | Elasticsearch

http://www.elasticsearch.org/blog/tool-help-routing-issues-elasticsearch-1-2-0/

REF:
peicheng-note: elasticsearch 相關 elasticsearch文章
http://peichengnote.blogspot.tw/search/label/elasticsearch
peicheng-note: [elasticsearch] document id _id field uuid
http://peichengnote.blogspot.tw/2014/05/elasticsearch-document-id-id-field-uuid.html
peicheng-note: [elasticsearch/logstash] logstash id 自動產生 document id "_id" automatic id generation
http://peichengnote.blogspot.tw/2014/04/elasticsearchlogstash-logstash-id.html

[elasticsearch] elasticsearch reindex processing 重建索引

在資料改變時常常有需求是 是需要把原始資料拿來做重新索引，
可能是，mapping改變，新增了某些欄位。

有種情況下，我們直接拿 elasticsearch  document 的 _source 來做一些處理，在把資料重新 index。

Use aliases

所以我們可以使用 alias 功能來達成 zero downtime。

1. 使用 scan 跟 scroll feature 來 reindex old index _source 的資料到 新的 index 。

2. 當完成時 switch alias 到新的 index。

ref

peicheng-note: elasticsearch 相關 elasticsearch文章
http://peichengnote.blogspot.tw/search/label/elasticsearch
peicheng-note: [elasticsearch] document id _id field uuid
http://peichengnote.blogspot.tw/2014/05/elasticsearch-document-id-id-field-uuid.html
peicheng-note: [elasticsearch/logstash] logstash id 自動產生 document id "_id" automatic id generation
http://peichengnote.blogspot.tw/2014/04/elasticsearchlogstash-logstash-id.html

[elasticsearch]elasticsearch-hadoop using mapreduce with elasticsearch

說到對於大資料的操作，不少人會直接想到 hadoop 裡面的MapReduce。
由於，elasticsearch是個搜索引擎。
常常有些人會把他們兩個混用，但是，必須注意的就在於如果在於單純的query，千萬不要在MapReduce裡面有自己做分段query。因為這樣是種疊床架屋的操作。

一個 component 是否可以 scalability，可以從他的架構上可不可以把平行處理或是把大的task拆分成多個比較小的task並且同時處理。

Mapreduce  splits and  Elasticsearch shard

這樣的概念同時蘊含在 hadoop 與 elasticsearch裡面。MapReduce 在運行時，會把input 的file split 成若干等份。在 Mapreduce  中，一個 input split 就代表著一個 mapper的運行。換言之， input splits 就表示就是把一份data分別給分塊給多個mapper來處理。

elasticsearch的shard (nums of part in which a index is divided into) 拆分也蘊含著這樣的概念。
每個 index 包含若干個 shards ，每個 shard 在 elasticsearch的 node上 實際儲存的是一個實際的 lucene index。
可閱讀之前文章了解 elasticsearch 稱為 分散式搜尋引擎的設計。

簡而言之，多個input splits就表示，同時有多個mapper會同時對來源的不同part做讀取的操作。

elasticsearch 官方所提供的 elasticsearch-hadoop lib 剛好就是針對 elasticsearch 與 mapreduce的特點去設計的。

elasticsearch/elasticsearch-hadoop
https://github.com/elasticsearch/elasticsearch-hadoop

elasticsearch-hadoop/mr/src/main/java/org/elasticsearch/hadoop/mr/EsInputFormat.java at master · elasticsearch/elasticsearch-hadoop
https://github.com/elasticsearch/elasticsearch-hadoop/blob/master/mr/src/main/java/org/elasticsearch/hadoop/mr/EsInputFormat.java
由上，可以看到 getsplits 與 shardinputsplit 的實作

    protected static class ShardInputSplit extends InputSplit implements org.apache.hadoop.mapred.InputSplit {



 

elasticsearch-hadoop 的 InputSplit 是採取有多少 shard 來決定 mapper的數量的。

reading from elasticsearch  使用 mapreduce query elasticsearch 

從 elasticsearch query資料時，預設 elasticsearch 每個index 的 shard數是5。所以，Hadoop 的 mapreduce 會起五個 map 到各個shard做操作。

官方的 lib 已經提供了一條 居於 elasticsearch 與 hadoop mapredcue performace 最高效設計。

writing to elasticsearch 使用 mapreduce 寫資料到 elasticsearch 

使用 elasticsearch-hadoop 時，會根據shard數起mapper 並把資料分發到不同map (shard) 平行的 寫入 elasticsearch。

Ref:

Elasticsearch for Apache Hadoop

http://www.elasticsearch.org/guide/en/elasticsearch/hadoop/current/index.html

[python][flask]Explore Flask now free

Robert Picard 的 Explore Flask -
Patterns and best practices for working with Flask.
Started on Kickstarter and currently in progress.

現在已經免費開放下載了。
Explore Flask — Explore Flask 1.0 documentation
http://exploreflask.com/index.html

[日記]140607 這天

現在凝結的這刻，在十年之後的這天。

不知道到底會怎樣 ~~

晚安 ~

 ~ 140607

[elasticsearch]search type - count 數量統計

elasticsearch 在使用情境上提供了多樣的 "search type" 可以使用。

search type 

在分散式的搜尋引擎設計中，在search 時，有時想要不同的面向的result。像是，單純想要知道count的數值，想要知道這個query 有多少hits，但是並不關心 docs

_search?search_type=count

There are different execution paths that can be done when executing a distributed search. The distributed search operation needs to be scattered to all the relevant shards and then all the results are gathered back. When doing scatter/gather type execution, there are several ways to do that, specifically with search engines.

One of the questions when executing a distributed search is how much results to retrieve from each shard. For example, if we have 10 shards, the 1st shard might hold the most relevant results from 0 till 10, with other shards results ranking below it. For this reason, when executing a request, we will need to get results from 0 till 10 from all shards, sort them, and then return the results if we want to ensure correct results.

[elasticsearch] Can't start up: not enough memory

[root@luwakh elasticsearch]# /etc/init.d/elasticsearch start
正在啟動 elasticsearch：                                   [  確定  ]
[root@luwakh elasticsearch]# Can't start up: not enough memory

env use elasticsearch-1.2.0.noarch.rpm 

1.2 以後要使用 java7 

並且設定java path

export JAVA_HOME=/usr/jdk64/jdk1.7.0_45

export PATH=$PATH:${JAVA_HOME}/bin

[hadoop][ambari]Problem: Ambari Agents May Fail to Register with Ambari Server.

在使用 ambari install hadoop 的時候可能會遇到下面問題
CentOS 6.5 and ambari  >1.4.x

2014-04-02 04:25:22,669 NetUtil.py:55 - Failed to connect to https://{ambari-server}:8440/cert/ca due to [Errno 1] _ssl.c:492: error:100AE081:elliptic curve routines:EC_GROUP_new_by_curve_name:unknown group

原來是 SSL 問題

1. yum upgrade openssl

upgrade 完後 restart ambari agent