[Elasticsearch] elasticsearch를 apache tajo의 external storage로 사용하기

Elastic/Elasticsearch 2015. 3. 27. 00:26


지난 주 부터 작업하던게 있는데요.

아직 어찌 될지는 알수 없지만 일단 안되더라도 필요하신 분들이 있을지 몰라 공유해 봅니다.


https://issues.apache.org/jira/plugins/servlet/mobile#issue/TAJO-1451


내용은 apache tajo에 external storage로 elasticsearch를 이용할수 있도록 컨트리븃 하고 있습니다.


정리하면 이런게 가능 합니다.

1. Sql을 이용한 elasticsearch index 질의 (ansi sql fully support 됩니다.)

2. Hdfs 나 기타 tajo 에서 지원하는 다양한 스토리지 데이터와 조인 (최근 1.5에서 inner hits가 추가 되었지만 비교할바가 안됩니다.)

3. 기타 다양한 활용도 가능 하겠죠. (상상력을 발휘하세요.)


뭐 최종 커밋이 안되더라도 제가 테스트 해보니 매우 유용해 보입니다. ^^


많은 분들이 데뷰에서 보여드린 es jdbc 드라이버를 원하실텐데요. 일단 이걸로 대리 만족 하심 어떨까해서 공유해 봅니다.

Trackbacks 0 : Comments 3
  1. Favicon of https://refactor.tistory.com BlogIcon 리팩토링 2015.04.09 15:00 신고 Modify/Delete Reply

    이 글과는 관련이 없습니다만. 몇가지 도움 받을 수 있을까 하여 문의드립니다.
    현재 5대의 서버로 서비스 구성중이며, 설정은 아래와 같습니다.
    문의 드릴 것은 두가지로
    1. 5대의 서버 중 한대가 장애가 난 것을 상정 한 경우 나머지 서버가 리밸런스 되면서 클라이언트에서 request_timeout이 발생합니다( 1~3분 가량 ). "cluster.routing.allocation.enable": "none" 이 옵션을 주면 장애가 발생하진 않습니다만, 실시간 검색서비스인데도 이 옵션을 주는 것이 타당한지요. 혹은 rebalance가 서비스에 영향을 주지 않는 형태로 동작하게 할 수 있는지요.

    2. 클러스터링을 하면 장애 발생시 순단이 발생하여 node.local 옵션을 주어 5대가 로컬로 돌며 서비스 하고 있습니다만. 간혼 ndex.merge.scheduler 이 이벤트가 발생하며, 클라이언트에서 request timeout이 발생하는 경우가 있습니다. 이 부분 역시도 서비스에 영향을 주지 않는 방안이 있는지요.

    장비 스펙은 32Gb, 32core, ssd 입니다.

    cluster.name: elasticsearch
    node.name: "node1"

    index.number_of_shards: 5
    index.number_of_replicas: 1

    bootstrap.mlockall: true

    network.publish_host: 192.168.171.117

    cluster.routing.allocation.node_initial_primaries_recoveries: 18
    cluster.routing.allocation.node_concurrent_recoveries: 4

    indices.recovery.max_bytes_per_sec: 100mb

    cluster.routing.allocation.cluster_concurrent_rebalance: 5
    cluster.routing.allocation.disk.threshold_enabled: true

    discovery.zen.ping.timeout: 10s
    discovery.zen.ping.multicast.enabled: false
    discovery.zen.ping.unicast.hosts: ["NWSCH01", "NWSCH02", "NWSCH03", "NWSCH04", "NWSCH05"]

    index.search.slowlog.threshold.query.warn: 10s
    index.search.slowlog.threshold.query.info: 5s
    index.search.slowlog.threshold.query.debug: 2s
    index.search.slowlog.threshold.query.trace: 500ms

    index.search.slowlog.threshold.fetch.warn: 1s
    index.search.slowlog.threshold.fetch.info: 800ms
    index.search.slowlog.threshold.fetch.debug: 500ms
    index.search.slowlog.threshold.fetch.trace: 200ms

    index.indexing.slowlog.threshold.index.warn: 10s
    index.indexing.slowlog.threshold.index.info: 5s
    index.indexing.slowlog.threshold.index.debug: 2s
    index.indexing.slowlog.threshold.index.trace: 500ms

    monitor.jvm.gc.young.warn: 1000ms
    monitor.jvm.gc.young.info: 700ms
    monitor.jvm.gc.young.debug: 400ms

    monitor.jvm.gc.old.warn: 10s
    monitor.jvm.gc.old.info: 5s
    monitor.jvm.gc.old.debug: 2s

    threadpool.bulk.type: cached
    threadpool.index.type: cached
    threadpool.search.type: cached
    indices.fielddata.cache.size: 25%
    indices.store.throttle.max_bytes_per_sec: 150mb
    indices.cluster.send_refresh_mapping: false

    • Favicon of https://jjeong.tistory.com BlogIcon jjeong 2015.04.13 15:53 신고 Modify/Delete

      1. 5대의 서버 중 한대가 장애가 난 것을 상정 한 경우 나머지 서버가 리밸런스 되면서 클라이언트에서 request_timeout이 발생합니다( 1~3분 가량 ). "cluster.routing.allocation.enable": "none" 이 옵션을 주면 장애가 발생하진 않습니다만, 실시간 검색서비스인데도 이 옵션을 주는 것이 타당한지요. 혹은 rebalance가 서비스에 영향을 주지 않는 형태로 동작하게 할 수 있는지요.

      [답변]
      --> none 으로 했을 경우 full replica 가 아닐경우 유실 데이터가 발생 할수 있습니다.
      --> timeout 을 적게 하기 위해서는 단일 shard 크기가 작아야 하지만 node 수의 제약이 대부분 있기 때문에 어렵습니다. 그럼에도 불구하고 shard 수를 늘리시면 도움은 됩니다.

      2. 클러스터링을 하면 장애 발생시 순단이 발생하여 node.local 옵션을 주어 5대가 로컬로 돌며 서비스 하고 있습니다만. 간혼 ndex.merge.scheduler 이 이벤트가 발생하며, 클라이언트에서 request timeout이 발생하는 경우가 있습니다. 이 부분 역시도 서비스에 영향을 주지 않는 방안이 있는지요.

      [답변]
      --> 장애 발생을 방지 하기 위해서 node topology 구성을 잘 하셔야 합니다. 기본 master node 는 두 개 이상으로 구성 하시는게 좋습니다.
      --> 너무 고급 사양의 서버로만 구성 하지 마시고 node 특성에 맞춰 서버 구성을 하셔서 클러스터 환경을 만드시는게 안정성과 성능적으로 효과를 보실 수 있습니다.
      --> merge 이벤트는 어차피 발생을 합니다. 이것도 shard 수를 늘리시면 도움이 됩니다.

      단순 답변이며, 질의/색인 특성과 문서 구조에 따라 달라질수 있으니 감안 하시고 참고 하시면 될 것 같습니다.

  2. Favicon of https://refactor.tistory.com BlogIcon 리팩토링 2015.04.13 17:13 신고 Modify/Delete Reply

    친절하신 답변 정말 감사드립니다. 일단은 샤드를 늘리고 테스트해보는 게 좋을 것 같네요 다시 한번 감사드립니다.

Write a comment