'IT/Database'에 해당되는 글 4건

해시 테이블은 보통 여러가지 이름으로 나오기도 합니다만, 예를 들면 python/swift의 dictionary, JSON, PHP의 배열, java/c++의 hashmap등

이것은 컴퓨터안에서 어떻게 실현했는지 설명하고자 합니다.

해시테이블의 특징

1개의 값에 대해서 유일한 키

응? 반대아니야? 라고 생각하는 사람 있을지 모르지만, 사실은 해시테이블을 만들었을때 다른 값을 같은 키로 나누어 버리는 경우도 있는데, 이것을 '충돌'이라고 부른다.

추가라고 부르는 것이 빠르다.

해시테이블도 배열계의 데이터구조의 한 종류로써, 다른 두가지는 배열과 링크리스트가 된다.

배열은 값을 부를때 주소가 있으면 한순간에 끝나지만, 1개의 값을 추가, 삭제하면, 다른 값도 채워지고, 이사하지 않으면 안된다.

링크 리스트는  추가가 빠르지만 (마지막에 들어가기 때문에), 호출 할 때 들어가있는 데이터를 하나씩 확인하지 않으면 안된다.

해시 테이블은 추가 할 때 해시 함수를 돌려 키에서 주소를 얻고 다른 값에 영향을주지 않는쪽으로 호출 할때 키 만 있으면 주소도 키에서 알게 즉시 값을 질문한다.

원리

key ====해시 함수를 건다.====> H(key) ====주소 GET====> (key|value)

이것으 흐름이다.

해시 함수

그러면 해시 함수는 어떤 것일까

간단하게 말하면 : 어떤 키가 와도 우선 고유 한 숫자로 변환하는 메서드

예 :

input = [23, 7, 11, 4, 10 (키)

이것은 분명히 5를 나누어 그 나머지를 가지고가는 경우에 중복이 없을 것

Hash 함수 h (key) = n mod 5

Hash 후 [3, 2, 1, 4, 0 (H (key))

해시 테이블에 사용하는 해시 함수는이 세 가지를 요구하고있다

알기 쉬울것

주소를 평균적으로 배부

키의 중복을 피할것

자주 사용되는 해시 함수

1.키가 숫자의 경우 일차 방정식을 취할 : H (key) = a · key + b

2.키가 숫자 인 경우 그 키는 징계 여부를 찾는 중복이 적은 일부를 가지고

3.키가 숫자의 경우, 그리고 징계도 없을 것 같고, 키를 제곱을 복용 제곱 한 결과 가운데 일부를 취한다. (제곱 한 결과 중간 부분은 숫자 전체와 관계 있기 때문에 중복을 피할 수)

4.키를 몇 등분하여 그것을 전부 더한다.

5.난수 함수를 사용

6.테이블의 길이를 나누어 나머지를 구한다.

다양한 소개했다고 생각하지만, 실제로 사용할 때 해시 함수는 중복없이 없으면 어느것이라도 좋다.

해시 테이블의 예

데이터:

이것을 이름 -> 성적의 형태로 해시테이블을 만들면 

이름의 생략어의 알파벳순이라는 해시함수를 사용하자.

이런 느낌

Drop in replacement for MySQL

모든 실제적인 목적을 위해 MariaDB는 동일한 MySQL 버전 (예 : MySQL 5.1 -> MariaDB 5.1, MariaDB 5.2 및 MariaDB 5.3)과 호환되는 바이너리 드롭입니다 .MySQL 5.5는 MariaDB 5.5와 호환되며 MariaDB 10.0에서도 호환됩니다. . 이것이 의미하는 바는 다음과 같습니다.

    데이터 W 테이블 정의 파일 (.frm) 파일은 2 진 호환 가능합니다.
        보기와의 비 호환성에 대해서는 아래 주를 참조하십시오!
    모든 클라이언트 API, 프로토콜 및 구조체는 동일합니다.
    모든 파일 이름, 바이너리, 경로, 포트, 소켓 등은 동일해야합니다.
    모든 MySQL 커넥터 (PHP, Perl, Python, Java, .NET, MyODBC, Ruby, MySQL C 커넥터 등)는 MariaDB와 동일하게 작동합니다.
        PHP5에 대해 알고 있어야 할 설치 문제가 있습니다 (예전 PHP5 클라이언트가 라이브러리 호환성을 확인하는 방법의 버그).
    mysql-client 패키지는 MariaDB 서버에서도 작동한다.
    공유 클라이언트 라이브러리는 MySQL 클라이언트 라이브러리와 바이너리 호환됩니다.

즉, 대부분의 경우 MySQL을 제거하고 MariaDB를 설치하면됩니다. (5.1과 같은 주 버전을 사용하는 경우 데이터 파일을 변환 할 필요가 없습니다.) 그러나 업그레이드를 마치려면 여전히 mysql_upgrade를 실행해야합니다. 이것은 당신의 mysql 권한과 이벤트 테이블이 MariaDB가 사용하는 새로운 필드로 업데이트되도록하기 위해 필요하다.

MySQL 코드베이스와 매월 병합하여 호환성을 유지하고 오라클이 추가 한 모든 기능과 버그 수정을 얻습니다.

또한 업그레이드 스크립트에 대한 많은 작업을 수행하여 MySQL 5.0에서 MySQL 5.1로 업그레이드하는 것보다 MySQL 5.0에서 MariaDB 5.1로 업그레이드하는 것이 더 쉬워졌습니다.

즉, MariaDB에는 MySQL에없는 새로운 옵션, 확장, 저장 엔진 및 버그 수정이 많이 있습니다. 다른 MariaDB 버전의 기능은 다른 MariaDB Releases에 있습니다.

Replication Compatibilit

MariaDB 5.1과 MySQL 5.1의 비 호환성

MariaDB가 MySQL보다 더 많은 정보를 제공하기 위해서는 MariaDB가 호환되지 않아야합니다.

다음은 MySQL 5.1 대신 MariaDB 5.1을 사용할 때 나타날 수있는 알려진 모든 사용자 수준 비 호환성 목록입니다.

    설치 패키지 이름은 MySQL 대신 MariaDB로 시작합니다.
    MariaDB가 많은 경우 MySQL보다 빠르기 때문에 타이밍이 다를 수 있습니다.
    MariaDB의 mysqld는 my.cnf 파일의 [mariadb] 섹션을 읽습니다.
    MariaDB와 정확히 같은 MariaDB 용으로 컴파일되지 않은 경우 이진 전용 저장소 엔진 라이브러리를 MariaDB와 함께 사용할 수 없습니다. (이는 서버 내부 구조 THD가 MySQL과 MariaDB 사이에서 다르므로 다른 MySQL 버전에서도 일반적입니다. 대부분의 사람들은 새로운 스토리지 엔진을로드하지 않으며 MariaDB는 MySQL보다 많은 스토리지 엔진을 제공하므로 문제가되지 않습니다.
    MySQL 5.1과 마찬가지로 MariaDB가 컬럼에서 NULL을 무시하지 않기 때문에 CHECKSUM TABLE은 다른 결과를 나타낼 수 있습니다 (MySQL의 향후 버전에서는 MariaDB와 동일한 방식으로 체크섬을 계산해야합니다). --old 옵션으로 mysqld를 시작하면 MariaDB에서 'old style'체크섬을 얻을 수있다. 그러나 MariaDB의 MyISAM 및 Aria 스토리지 엔진은 내부적으로 새로운 체크섬을 사용하므로 --old를 사용하는 경우 체크섬을 행 단위로 계산해야하므로 CHECKSUM 명령의 속도가 느려집니다.
    느린 쿼리 로그에는 쿼리에 대한 자세한 정보가 있습니다. 느린 쿼리 로그를 구문 분석하는 스크립트가있는 경우 문제가 될 수 있습니다.
    기본적으로 MariaDB는 내부 임시 테이블을 처리하기 위해 Aria 스토리지 엔진을 기본적으로 활성화했기 때문에 MySQL보다 약간 더 많은 메모리를 사용합니다. 성능을 희생시키면서 MariaDB에 메모리가 거의 필요하지 않은 경우 aria_pagecache_buffer_size 값을 1M (기본값은 128M)으로 설정할 수 있습니다.
    새로운 명령 옵션, MariaDB의 새로운 기능 또는 새로운 스토리지 엔진을 사용하는 경우 더 이상 MySQL과 MariaDB간에 쉽게 이동할 수 없습니다.

MariaDB 5.2와 MySQL 5.1의 비 호환성

이 목록은 MariaDB 5.1과 MySQL 5.1 사이의 목록과 동일하며 추가 된 항목은 다음과 같습니다.

     새 SQL_MODE 값이 추가되었습니다 : IGNORE_BAD_TABLE_OPTIONS. 설정되지 않은 경우 선택한 스토리지 엔진에서 지원하지 않는 테이블, 필드 또는 색인 속성 (옵션)을 사용하면 오류가 발생합니다. 이 변경으로 인해 mysql 데이터베이스의 잘못 정의 된 테이블에 대한 에러 로그에 경고가 발생하고 mysql_upgrade로이를 수정하십시오.

모든 실제적인 목적을 위해, MariaDB 5.2는 MariaDB 5.1 및 MySQL 5.1을 대체합니다.

MariaDB 5.3과 MySQL 5.1 및 MariaDB 5.2 간의 비 호환성

정의가있는 뷰 ALGORITHM = MERGE 또는 ALGORITHM = TEMPTABLE이 MariaDB 5.2와 MariaDB 5.3 사이에서 실수로 바뀌 었습니다! 이 정의 중 하나로 만든보기를 다시 만들어야합니다!

MariaDB가 무엇이 잘못되었는지에 대한 메시지에 더 많은 정보를 제공하기 때문에 잘못된 변환과 관련된 몇 가지 오류 메시지가 다릅니다.

•     MariaDB 관련 오류의 오류 번호가 1900 년부터 시작되어 MySQL 오류와 충돌하지 않도록했습니다.
      마이크로 초는 이제 모든 상황에서 작동합니다. 일부 상황에서 MySQL은 날짜와 시간에서 마이크로 초 부분을 잃어 버렸습니다.
      UNIX_TIMESTAMP (constant-date-string)는 MariaDB에서 6 자리 소수점이있는 타임 스탬프를 반환하는 반면, MySQL은 소수점없이 반환합니다. 파티션 함수로 UNIX_TIMESTAMP ()를 사용하면이 문제가 발생할 수 있습니다. FLOOR (UNIX_TIMESTAMP (..))를 사용하거나 날짜 문자열을 20080101000000과 같은 날짜 번호로 변경하여이 문제를 해결할 수 있습니다.
      MariaDB는 날짜, 날짜 시간 및 시간 소인 값을 엄격하게 검사합니다. 예를 들어 UNIX_TIMESTAMP ( 'x')는 이제 0 대신 NULL을 반환합니다.
      이전 --maria- 시작 옵션이 제거되었습니다. 대신에 --aria- 접두어를 사용해야합니다. (MariaDB 5.2는 - 마리아와 - 아리아를 모두 지원합니다)
      SHOW PROCESSLIST에는 일부 명령의 진행 상황을 보여주는 추가 진행 열이 있습니다. --old-mode = NO_PROGRESS_INFO 또는 --old 플래그 (OLD_MODE 참조)를 사용하여 mysqld를 시작하여 비활성화 할 수 있습니다.
      INFORMATION_SCHEMA.PROCESSLIST에는 진행보고를위한 세 개의 새로운 열이 있습니다 : STAGE, MAX_STAGE 및 PROGRESS.
      / * M으로 시작하는 긴 주석! 또는 / * M! #####이 실행됩니다.
      mysqld를 시작할 때 max_user_connections = 0 (연결 수를 의미)을 사용하면 mysqld가 실행 중일 때 전역 변수를 더 이상 변경할 수 없다. mysqld가 max_user_connections = 0으로 시작될 때 계수 구조 (각 연결마다 뮤텍스가 포함됨)를 할당하지 않기 때문입니다. 나중에 변수를 변경하면 잘못된 카운터로 이어질 수 있습니다. 런타임에이 변수를 변경할 수 있으려면 시작시 높은 값으로 설정하십시오.
      max_user_connections (전역 변수와 GRANT 옵션 모두)를 -1로 설정하여 사용자가 서버에 연결하지 못하게 할 수 있습니다. 전역 max_user_connections 변수는 SUPER 특권이있는 사용자에게 영향을주지 않습니다.
      IGNORE 지시어는 치명적 오류와 같은 모든 오류를 무시하지 않고 무시해도 안전합니다.

MariaDB Server는 모든 계층에서 확장 가능하고 안전한 엔터프라이즈 급 데이터베이스입니다.

IT 인프라의 중심에 존재하는 데이터베이스는 모든 유형의 애플리케이션에 강력하고 민첩하며 안전한 기반을 제공해야합니다. 디지털 변환, IoT (Internet of Things) 및 모바일에서 비즈니스를 수행하는 새로운 방법은 느리게 움직이는 레거시 시스템의 경계를 뛰어 넘는 응답 성, 데이터베이스 보안 및 성능을 필요로합니다. MariaDB Server는 구형과 신형 사이에 다리를 놓고 있습니다. 현대적이고 확장 가능한 아키텍처는 기업이 새로운 응용 프로그램을 지속적으로 혁신하고 기존 시스템을 현대화 할 수있는 기반을 제공합니다.

익숙한 SQL 인터페이스와 개방 된 확장 성을 결합한 MariaDB는 보안 데이터베이스와 안정적이고 구성 가능한 데이터 계층을 결합하여 광범위한 사용 사례를 포괄하여 혁신을 지원합니다.

"MariaDB는 고품질, 현대 서비스 및 안전한 데이터 관리 기능으로 인해 오라클보다 선정되었습니다."

확장 가능한 아키텍처

     단일 배포로 다양한 사용 사례 지원 - 트랜잭션, 분석, 메모리 내, 공간 및 NoSQL 사용 사례
     특정 사용 사례에 맞게 스토리지 엔진을 사용자 정의하십시오. 선택할 수있는 옵션 : InnoDB, ColumnStore, Aria, MyRocks, CONNECT Engines 등
     열린 커뮤니티의 혁신을 활용하십시오.
     독특한 유스 케이스에 기반한 새로운 기능으로 MariaDB를 쉽게 확장 할 수 있습니다.

Enterprise-Grade Database Security

보안은 모든 엔터프라이즈 배포에서 가장 중요한 요구 사항입니다.

데이터의 이동 여부에 관계없이 MariaDB Server는 데이터를 보호하기 위해 네트워크, 서버 및 애플리케이션의 모든 계층에서 암호화 및 인증을 제공합니다.

MariaDB 보안 데이터베이스 :

     MariaDB Connectors에서 TLS / SSL 지원을 통해 데이터 이동 암호화로 네트워크 수준 보안 공격으로부터 보호
     Amazon 및 eperi와 같은 기본 암호화 및 선택적 외부 키 관리 공급자를 사용하여 데이터를 안전하게 보호합니다.
     보안, 규제 및 운영 위험으로부터 보호합니다.

High Availability with Distributed Environment

미션 크리티컬 애플리케이션의 가동 시간은 항상 100 %입니다.

Galera로 구동되는 MariaDB Server의 클러스터 기술은 동기 멀티 마스터 클러스터를 제공하고 분산 환경에 대한 고 가용성을 제공합니다.

MariaDB 고 가용성 :

     다중 마스터 클러스터 기술인 Galera의 완벽한 통합을 포함합니다.
     고 가용성을위한 동기 및 반 동기 복제 제공
     자동 멤버십 제어 및 노드 연결을 통해 장애로부터 보호합니다.

Flexible Scalability

웹 규모의 요구 사항을 지원하도록 응용 프로그램을 쉽게 확장 할 수 있습니다.

MariaDB Server는 최대 수요 요구 사항을 충족시키고 대규모 환경을 관리하는 여러 가지 방법을 제공합니다. MaxScale에서 Galera Cluster에 이르기까지 MariaDB 기술은 데이터 및 응용 프로그램 관리를 간소화합니다.

MariaDB 확장 성 :

     클러스터에서 노드를 추가 및 제거하여 트랜잭션 처리량 읽기 및 쓰기를 쉽게 확장 할 수 있습니다.
     플러그 형 스토리지 엔진을 사용하여 대용량 데이터 세트의 파티셔닝 및 샤딩을 간소화합니다.
     MariaDB의 수상 경력에 빛나는 MaxScale을 사용하여 보안, 확장 및 부하 분산 관리

Optimized Performance in All Levels

데이터베이스의 모든 계층에 대해 최적화 된 성능. 많은 애플리케이션에서 성능이 가장 중요한 요구 사항입니다. MariaDB는 데이터베이스의 모든 계층에서 성능 최적화를 통해 수평 확장을 넘어

     특수한 용도로 최적화 된 스토리지 엔진을 선택하십시오.
     로드를 기반으로 동적으로 최적화되는 자체 조정 적응 형 스레드 풀
     지능형 최적화 프로그램은 쿼리 성능과 복잡한 쿼리 처리를 향상시킵니다.
     하드웨어 공급 업체와의 강력한 공동 작업으로 CPU, 코어 및 RAM 최적화

MariaDB MaxScale을 사용하면 데이터베이스 클러스터의 확장 성, 가용성 및 보안을 쉽게 관리 할 수 있습니다.

MariaDB MaxScale은 수평 확장 배치에서 보안, 확장 성 및 고 가용성을 관리하는 차세대 데이터베이스 프록시입니다. MaxScale을 사용하면 응용 프로그램 성능을 저하시키지 않으면 서 관리 데이터베이스 프로세스가 실행됩니다.

MariaDB MaxScale의 플러그인 아키텍처는 유연성을 높이고 사용자 정의를 지원하도록 설계되었습니다. 확장 가능한 플러그인 아키텍처를 사용하면 커뮤니티 회원뿐만 아니라 특정 유스 케이스에 기능을 확장하려는 MariaDB Enterprise 고객이 새로운 플러그인을 쉽게 만들 수 있습니다.

왜 MariaDB MaxScale인가?

1.Secure Your Database

MaxScale은 SQL 주입 및 DDoS와 같은 보안 공격을 방지합니다.

데이터베이스는 중요한 정보에 액세스하려는 해커의 목표가 될 것입니다. MaxScale은 원치 않는 액세스를 완화하는 데 적극적인 자세를 취합니다. MaxScale은 모든 수준에서 데이터베이스를 보호하는 고급 데이터베이스 방화벽 기능을 제공합니다.

     안전한 데이터 액세스를위한 엔드 투 엔드 SSL 지원 및 로컬 전용 액세스 활용
     유연한 화이트리스트 및 쿼리 동작의 블랙리스트와 함께 SQL 주입 공격 방지
     내장 된 속도 제한 규칙을 구성하여 DDoS 공격 완화

2.Manage Your Scale-Out Deployment

분산 배포 관리를 단순화하는 단일 액세스 지점

MaxScale은 데이터베이스 프록시로서 클라이언트 응용 프로그램에 대한 빠른 응답을 유지하면서 수평 적 데이터베이스 확장을 가능하게합니다. MariaDB MaxScale은 다음을 통해 트랜잭션 확장 성, 데이터 확장 성 및 binlog 확장 성을 제공합니다.

     지능형 동적 SQL- 쿼리 라우터를 통해 쿼리 응답 시간 단축
     테넌트 기반 쿼리 라우팅을 통한 단순화 된 데이터 샤딩
     Binlog 서버를 사용한 고성능 복제 스케일링

3.Ensure High Availability

MaxScale 자동 장애 조치 및 비동기 복제로 다운 타임을 최소화하십시오.

분산 환경에서 단일 노드의 장애는 애플리케이션 가동 시간에 부정적인 영향을 미칠 수 있습니다. MaxScale은 데이터베이스 백엔드를 제어하여 모든 노드 수준 장애로부터 응용 프로그램 성능을 보호합니다.

     자동 데이터베이스 장애 조치
     비동기 데이터베이스 및 응용 프로그램 업그레이드

     액티브 / 패시브 및 액티브 / 스탠바이 MaxScale 구성

4.Data Streaming

실시간 분석 데이터 및 기계 학습을위한 데이터 호수 환경에 대한 실시간 트랜잭션 데이터.

트랜잭션이 커밋 될 때 데이터 흐름이 항상 종료되는 것은 아닙니다. 이러한 이유로 MaxScale은 쉽게 소모 할 수있는 binlog 이벤트 스트림을 제공합니다. 다운 스트림 소비자가 비동기로 작업을 수행하거나 데이터를 Hadoop과 같은 분석 플랫폼에 유지할 수있는 이벤트 소싱 패턴으로 스트림을 활용합니다.

     실시간으로 Kafka와 같은 메시징 시스템에 트랜잭션 데이터 스트리밍
     binlog 이벤트를 AVRO 또는 JSON으로 표시하여 쉽게 다운 스트림으로 쉽게 사용할 수 있습니다.
     기계 학습, 실시간 분석 및 기타 비동기 작업을 위해 스트리밍 데이터 활용