Cassandra - Data Design Solution для службы входа

Question

Мне нужна ваша помощь, чтобы спроектировать структуру для простого входа в систему. Он содержит около 100 000 000 клиентов, и каждый из них может иметь около 10 различных имен входа - в результате получается 1 000 000 000 различных имен входа.

Каждый клиент содержит следующие данные:

• одно-много имен для входа в виде строки длиной не более 20 символов UTF-8
• Идентификатор как длинный - у одного клиента только один идентификатор
• пол
• дата рождения
• имя
• пароль как MD5

В процессе входа в систему необходимо найти пользователя по имени для входа.

Данные в Cassandra реплицируются - это необходимо для получения всех необходимых данных для входа в систему за один вызов. Также обычно мы ожидаем низкий трафик записи и большой трафик чтения - следует избегать циклических поездок для чтения данных.

Ниже я описал две возможные модели данных cassandra на основе примера: у нас два пользователя, у первого пользователя два входа, а у второго три входа

A) Узкие ряды

• ключ строки содержит логин - это основной критерий поиска
• данные входа в систему реплицируются - каждый возможный вход в систему сохраняется как одна строка, которая содержит все пользовательские данные - 10 имен входа для одного клиента создают 10 строк, где каждая строка имеет свой ключ и одинаковое содержимое

    // first 3 rows has different key and the same replicated data
        alfred.tester@xyz.de {
          id: 1122
          gender: MALE
          birthdate: 1987.11.09
          name: Alfred Tester
          pwd: e72c504dc16c8fcd2fe8c74bb492affa  
        },
        alfred@aad.de {
          id: 1122
          gender: MALE
          birthdate: 1987.11.09
          name: Alfred Tester
          pwd: e72c504dc16c8fcd2fe8c74bb492affa  
        },
        alf@dd.de {
          id: 1122
          gender: MALE
          birthdate: 1987.11.09
          name: Alfred Tester
          pwd: e72c504dc16c8fcd2fe8c74bb492affa  
        },

    // two following rows has again the same data for second customer
        manfred@xyz.de {
          id: 1133
          gender: MALE
          birthdate: 1997.02.01
          name: Manfredus Maximus
          pwd: e44c504ff16c8fcd2fe8c74bb492adda  
        },
        roberrto@xyz.de {
          id: 1133
          gender: MALE
          birthdate: 1997.02.01
          name: Manfredus Maximus
          pwd: e44c504ff16c8fcd2fe8c74bb492adda  
        }

B) Строки, сгруппированные по алфавиту

• Количество строк ограничено - например, первая буква от имени пользователя
• Каждая строка содержит все логины, которые совпадают с ключом строки - строка с ключом 'a' содержит все логины, которые начинаются с 'a'
• Данные могут быть несбалансированными, но мы избегаем узких строк - это может оказать положительное влияние на производительность (??)
• чтобы избежать супер-столбцов, каждая строка содержит непосредственно столбцы, где имя столбца - это логин пользователя, а значение столбца - это соответствующие данные в виде сериализованной формы (я хотел бы, чтобы они читались человеком)

    a {
        alfred.tester@xyz.de:"1122;MALE;1987.11.09;
                                 Alfred Tester;e72c504dc16c8fcd2fe8c74bb492affa",

        alfred@aad.de@xyz.de:"1122;MALE;1987.11.09;
                                 Alfred Tester;e72c504dc16c8fcd2fe8c74bb492affa",

        alf@dd.de@xyz.de:"1122;MALE;1987.11.09;
                                 Alfred Tester;e72c504dc16c8fcd2fe8c74bb492affa"
      },

    m {
        manfred@xyz.de:"1133;MALE;1997.02.01;
                  Manfredus Maximus;e44c504ff16c8fcd2fe8c74bb492adda"    
      },

    r {
        roberrto@xyz.de:"1133;MALE;1997.02.01;
                  Manfredus Maximus;e44c504ff16c8fcd2fe8c74bb492adda"    

      }

Какое решение лучше, особенно для производительности чтения? У тебя есть идея получше?

Answer 1

Это что-то вроде кросспоста , но я также отвечу на ваш вопрос здесь.

Если вы всегда используете имена входа в качестве ключа поиска, то вы по сути создаете хранилище значений ключей. Кассандра, безусловно, станет отличным хранилищем ключей-значений, если вы будете использовать его как один, который будет вашей худой моделью рядов.

Широкие строки используются, когда вам нужно ответить на несколько более сложные запросы, например, когда вы имеете дело с данными временных рядов, списками или наборами. Причина, по которой модели данных с широкими строками иногда описываются как «более производительные», заключается в том, что они предлагают чрезвычайно хорошую производительность для тех чуть более сложных типов запросов. Попытка использовать узкие модели строк для ответа на эти типы запросов может быть очень неэффективной.

Но нет необходимости деформировать хранилище ключей-значений, чтобы оно подходило для модели с широкими рядами - оно будет отлично работать с узкими рядами.